{"id":5244,"date":"2017-04-16T20:28:11","date_gmt":"2017-04-16T20:28:11","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/c-17-avoid-copying-with-std-string-view\/"},"modified":"2023-06-26T12:18:13","modified_gmt":"2023-06-26T12:18:13","slug":"c-17-avoid-copying-with-std-string-view","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/c-17-avoid-copying-with-std-string-view\/","title":{"rendered":"C++17 – Avoid Copying with std::string_view"},"content":{"rendered":"

The purpose of std::string_view<\/span> is to avoid copying data already owned by someone else and of which only a non-mutating view is required. So, this post is mainly about performance.<\/p>\n

<\/p>\n

 <\/p>\n

Today,  I write about a main feature of C++17.<\/p>\n

\"timeline\"<\/p>\n

I assume that you know a little bit about std::string_view.<\/span> If not, read the previous post C++17 – What’s New in the library<\/a> first. A C++ string is like a thin wrapper storing data on the heap. Therefore, a memory allocation often kicks in when you deal with C and C++ strings. Let’s have a look.<\/p>\n

Small string optimization<\/h2>\n

You will see in a few lines why I called this paragraph small string optimization.<\/p>\n

\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n30\r\n31\r\n32\r\n33\r\n34<\/pre>\n<\/td>\n
\n
\/\/ sso.cpp<\/span>\r\n\r\n#include <iostream><\/span>\r\n#include <string><\/span>\r\n\r\nvoid<\/span>* operator<\/span> new(std::size_t<\/span> count){\r\n    std::cout << \"   \"<\/span> << count << \" bytes\"<\/span> << std::endl;\r\n    return<\/span> malloc(count);\r\n}\r\n\r\nvoid<\/span> getString(const<\/span> std::string& str){}\r\n\r\nint<\/span> main() {\r\n\r\n    std::cout << std::endl;\r\n\r\n    std::cout << \"std::string\"<\/span> << std::endl;\r\n\r\n    std::string small = \"0123456789\"<\/span>;\r\n    std::string substr = small.substr(5);\r\n    std::cout << \"   \"<\/span> << substr << std::endl;\r\n\r\n    std::cout << std::endl;\r\n\r\n    std::cout << \"getString\"<\/span> << std::endl;\r\n\r\n    getString(small);\r\n    getString(\"0123456789\"<\/span>);\r\n    const<\/span> char<\/span> message []= \"0123456789\"<\/span>;\r\n    getString(message);\r\n\r\n    std::cout << std::endl;\r\n\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
I overloaded the global operator new<\/span> in lines 6-9. Therefore, you can see which operation causes a memory allocation. Come on. That’s easy. Lines 19, 20, 28, and 29 cause a memory allocation. Here you have the numbers:<\/p>\n
 \"sso\"<\/p>\n
What the …? I said. The strings store their data on the heap. But that is only true if the string exceeds an implementation-dependent size. This size for std::string<\/span> is 15 for MSVC and GCC and 23 for Clang.<\/p>\n
That means, on the contrary, small strings are stored directly in the string object. Therefore, no memory allocation is required.<\/p>\n
From now on, my strings will always have at least 30 characters. So, I do have not to reason about small string optimization. Let’s start once more but this time with longer strings.<\/p>\n<\/p>\n
No memory allocation required<\/h2>\n
Now, std::string_view<\/span> shines brightly. Contrary to std::string<\/span>, std::string_view<\/span> allocates no memory. Here is the proof.<\/p>\n
 <\/p>\n
\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n30\r\n31\r\n32\r\n33\r\n34\r\n35\r\n36\r\n37\r\n38\r\n39\r\n40\r\n41\r\n42\r\n43\r\n44\r\n45\r\n46\r\n47\r\n48\r\n49\r\n50\r\n51\r\n52\r\n53\r\n54\r\n55<\/pre>\n<\/td>\n
\n
\/\/ stringView.cpp<\/span>\r\n\r\n#include <cassert><\/span>\r\n#include <iostream><\/span>\r\n#include <string><\/span>\r\n\r\n#include <string_view><\/span>\r\n\r\nvoid<\/span>* operator<\/span> new(std::size_t<\/span> count){\r\n    std::cout << \"   \"<\/span> << count << \" bytes\"<\/span> << std::endl;\r\n    return<\/span> malloc(count);\r\n}\r\n\r\nvoid<\/span> getString(const<\/span> std::string& str){}\r\n\r\nvoid<\/span> getStringView(std::string_view strView){}\r\n\r\nint<\/span> main() {\r\n\r\n    std::cout << std::endl;\r\n\r\n    std::cout << \"std::string\"<\/span> << std::endl;\r\n\r\n    std::string large = \"0123456789-123456789-123456789-123456789\"<\/span>;\r\n    std::string substr = large.substr(10);\r\n\r\n    std::cout << std::endl;\r\n\r\n    std::cout << \"std::string_view\"<\/span> << std::endl;\r\n\r\n    std::string_view largeStringView{large.c_str(), large.size()};\r\n    largeStringView.remove_prefix(10);\r\n\r\n    assert(substr == largeStringView);\r\n\r\n    std::cout << std::endl;\r\n\r\n    std::cout << \"getString\"<\/span> << std::endl;\r\n\r\n    getString(large);\r\n    getString(\"0123456789-123456789-123456789-123456789\"<\/span>);\r\n    const<\/span> char<\/span> message []= \"0123456789-123456789-123456789-123456789\"<\/span>;\r\n    getString(message);\r\n\r\n    std::cout << std::endl;\r\n\r\n    std::cout << \"getStringView\"<\/span> << std::endl;\r\n\r\n    getStringView(large);\r\n    getStringView(\"0123456789-123456789-123456789-123456789\"<\/span>);\r\n    getStringView(message);\r\n\r\n    std::cout << std::endl;\r\n\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
Once more. Memory allocations occur in lines 24, 25, 41, and 43. But what happens in the corresponding calls in lines 31, 32, 50, and 51? No memory allocation!<\/p>\n
\"stringView\"<\/p>\n
That is impressive. You can imagine this is a performance boost because memory allocation is costly. You can observe this performance boost very well if you build substrings of existing strings.<\/p>\n
O(n) versus O(1)<\/h2>\n
std::string<\/span> and std::string_view<\/span> have both a method substr.<\/span> The method of the std::string <\/span>returns a substring, but the method of the std::string_view <\/span>returns a view of a substring. This sounds not so thrilling. But there is a big difference between both methods. std::string::substr<\/span> has linear complexity. std::string_view::substr<\/span> has constant complexity. That means that the performance of the operation on the std::string<\/span> is directly dependent on the size of the substring, but the performance of the operation on the std::string_view<\/span> is independent of the size of the substring.<\/p>\n
Now I’m curious. Let’s make a simple performance comparison.<\/p>\n
 <\/p>\n
\n\n\n\n
\n
 1\r\n 2\r\n 3\r\n 4\r\n 5\r\n 6\r\n 7\r\n 8\r\n 9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n30\r\n31\r\n32\r\n33\r\n34\r\n35\r\n36\r\n37\r\n38\r\n39\r\n40\r\n41\r\n42\r\n43\r\n44\r\n45\r\n46\r\n47\r\n48\r\n49\r\n50\r\n51\r\n52\r\n53\r\n54\r\n55\r\n56\r\n57\r\n58\r\n59<\/pre>\n<\/td>\n
\n
\/\/ substr.cpp<\/span>\r\n\r\n#include <chrono><\/span>\r\n#include <fstream><\/span>\r\n#include <iostream><\/span>\r\n#include <random><\/span>\r\n#include <sstream><\/span>\r\n#include <string><\/span>\r\n#include <vector><\/span>\r\n\r\n#include <string_view><\/span>\r\n\r\nstatic<\/span> const<\/span> int<\/span> count = 30;\r\nstatic<\/span> const<\/span> int<\/span> access = 10000000;\r\n\r\nint<\/span> main(){\r\n\r\n    std::cout << std::endl;\r\n\r\n    std::ifstream inFile(\"grimm.txt\"<\/span>);\r\n\r\n    std::stringstream strStream;\r\n    strStream <<  inFile.rdbuf();\r\n    std::string grimmsTales = strStream.str();\r\n\r\n    size_t<\/span> size = grimmsTales.size();\r\n\r\n    std::cout << \"Grimms' Fairy Tales size: \"<\/span> << size << std::endl;\r\n    std::cout << std::endl;\r\n\r\n    \/\/ random values<\/span>\r\n    std::random_device seed;\r\n    std::mt19937 engine(seed());\r\n    std::uniform_int_distribution<> uniformDist(0, size - count - 2);\r\n    std::vector<int<\/span>> randValues;\r\n    for<\/span> (auto<\/span> i = 0; i <  access; ++i) randValues.push_back(uniformDist(engine));\r\n\r\n    auto<\/span> start = std::chrono::steady_clock::now();\r\n    for<\/span> (auto<\/span> i = 0; i  < access; ++i ) {\r\n        grimmsTales.substr(randValues[i], count);\r\n    }\r\n    std::chrono::duration<double<\/span>> durString= std::chrono::steady_clock::now() - start;\r\n    std::cout << \"std::string::substr:      \"<\/span> << durString.count() << \" seconds\"<\/span> << std::endl;\r\n\r\n    std::string_view grimmsTalesView{grimmsTales.c_str(), size};\r\n    start = std::chrono::steady_clock::now();\r\n    for<\/span> (auto<\/span> i = 0; i  < access; ++i ) {\r\n        grimmsTalesView.substr(randValues[i], count);\r\n    }\r\n    std::chrono::duration<double<\/span>> durStringView= std::chrono::steady_clock::now() - start;\r\n    std::cout << \"std::string_view::substr: \"<\/span> << durStringView.count() << \" seconds\"<\/span> << std::endl;\r\n\r\n    std::cout << std::endl;\r\n\r\n    std::cout << \"durString.count()\/durStringView.count(): \"<\/span> << durString.count()\/durStringView.count() << std::endl;\r\n\r\n    std::cout << std::endl;\r\n\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
 <\/p>\n
Before I present the numbers, let me say a few words about my performance test. The key idea of the performance test is to read in a large file as a std::string<\/span> <\/span>and create a lot of substrings with std::string<\/span> and std::string_view<\/span>. I’m precisely interested in how long this creation of substrings will take.<\/p>\n
I used “Grimm’s Fairy Tales” as my long file. What else should I use? The string grimmTales<\/span> (line 24) has the content of the file. I fill the std::vector<int><\/span> in line 37 with access<\/span> number (10’000’000) of values in the range [0, size – count – 2] (line 34). Now the performance test starts. I create in lines 39 to 41 access<\/span> substrings of the fixed-length count. <\/span>The count <\/span>is 30. Therefore, no small string optimization kicks in. I do the same in lines 47 to 49 with the std::string_view. <\/span><\/p>\n
Here are the numbers. You see the length of the file, the numbers for std::string::substr<\/span> and std::string_view::substr,<\/span> and the ratio between both. I used GCC 6.3.0 as the compiler.<\/p>\n
Size 30<\/h3>\n
Only out of curiosity. The numbers without optimization.<\/p>\n
\"substr\"<\/p>\n
But now to the more critical numbers. GCC with complete optimization.<\/p>\n
\"substrOptimized\"<\/p>\n
 <\/p>\n
The optimization makes no big difference in the case of std::string<\/span> but a significant difference in the case of std::string_view<\/span>.  Making a substring with std::string_view<\/span> is about 45 times faster than using std::string<\/span>. If that is not a reason to use std::string_view?<\/span> <\/p>\n
Different sizes<\/h3>\n
Now I’m becoming more curious. What will happen if I play with the size count<\/span> of the substring? Of course, all numbers are with maximum optimization. I rounded them to the 3rd decimal place.<\/p>\n
 \"numbers\"<\/h2>\n
 <\/p>\n
I’m not astonished; the numbers reflect the complexity guarantees of std::string::substr<\/span> versus std::string_view::substr<\/span>. The complexity of the first is linearly dependent on the substring’s size; the second is independent of the size of the substring. In the end, the std::string_view<\/span> drastically outperforms std::string<\/span>.<\/p>\n
What’s next?<\/h2>\n
There is more to write about std::any<\/span>, std::optional<\/span>, and std::variant<\/span>. Wait for the next post<\/a>.<\/p>\n
 <\/p>\n<\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
The purpose of std::string_view is to avoid copying data already owned by someone else and of which only a non-mutating view is required. So, this post is mainly about performance.<\/p>\n","protected":false},"author":21,"featured_media":4724,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[370],"tags":[463],"class_list":["post-5244","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-c-17","tag-string"],"_links":{"self":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5244","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/comments?post=5244"}],"version-history":[{"count":1,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5244\/revisions"}],"predecessor-version":[{"id":6875,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/posts\/5244\/revisions\/6875"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media\/4724"}],"wp:attachment":[{"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/media?parent=5244"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/categories?post=5244"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.modernescpp.com\/index.php\/wp-json\/wp\/v2\/tags?post=5244"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}