c++ c++17 string string-view

How exactly is std::string_view faster than const std::string&?


std::string_view has made it to C++17 and it is widely recommended to use it instead of const std::string&.

One of the reasons is performance.

Can someone explain how exactly std::string_view is/will be faster than const std::string& when used as a parameter type? (let’s assume no copies in the callee are made)


  • 12

    std::string_view is just an abstraction of the (char * begin, char * end) pair. You use it when making a std::string would be an unnecessary copy.

    – QuestionC

    Oct 19, 2016 at 17:51

  • In my opinion the question is not exactly which one is faster, but when to use them. If I need some manipulation on string and it is not permanent and/or keep the original value, string_view is perfect because I don’t need to make a copy of string to it. But if I only need to check something on string using string::find for example, then the reference is better.

    Dec 27, 2017 at 13:04

  • 1

    @QuestionC you use it when you don’t want your API to restrict to std::string (string_view can accept raw arrays, vectors, std::basic_string<> with non-default allocators etc. etc. etc. Oh, and other string_views obviously)

    – sehe

    Mar 19, 2018 at 12:32


std::string_view is faster in a few cases.

First, std::string const& requires the data to be in a std::string, and not a raw C array, a char const* returned by a C API, a std::vector<char> produced by some deserialization engine, etc. The avoided format conversion avoids copying bytes, and (if the string is longer than the SBO¹ for the particular std::string implementation) avoids a memory allocation.

void foo( std::string_view bob ) {
  std::cout << bob << "\n";
int main(int argc, char const*const* argv) {
  foo( "This is a string long enough to avoid the std::string SBO" );
  if (argc > 1)
    foo( argv[1] );

No allocations are done in the string_view case, but there would be if foo took a std::string const& instead of a string_view.

The second really big reason is that it permits working with substrings without a copy. Suppose you are parsing a 2 gigabyte json string (!)². If you parse it into std::string, each such parse node where they store the name or value of a node copies the original data from the 2 gb string to a local node.

Instead, if you parse it to std::string_views, the nodes refer to the original data. This can save millions of allocations and halve memory requirements during parsing.

The speedup you can get is simply ridiculous.

This is an extreme case, but other “get a substring and work with it” cases can also generate decent speedups with string_view.

An important part to the decision is what you lose by using std::string_view. It isn’t much, but it is something.

You lose implicit null termination, and that is about it. So if the same string will be passed to 3 functions all of which require a null terminator, converting to std::string once may be wise. Thus if your code is known to need a null terminator, and you don’t expect strings fed from C-style sourced buffers or the like, maybe take a std::string const&. Otherwise take a std::string_view.

If std::string_view had a flag that stated if it was null terminated (or something fancier) it would remove even that last reason to use a std::string const&.

There is a case where taking a std::string with no const& is optimal over a std::string_view. If you need to own a copy of the string indefinitely after the call, taking by-value is efficient. You’ll either be in the SBO case (and no allocations, just a few character copies to duplicate it), or you’ll be able to move the heap-allocated buffer into a local std::string. Having two overloads std::string&& and std::string_view might be faster, but only marginally, and it would cause modest code bloat (which could cost you all of the speed gains).

¹ Small Buffer Optimization

² Actual use case.


  • 19

    You also lose ownership. Which is only of interest if the string is returned and it might have to be anything besides a sub-string of a buffer which is guaranteed to survive long enough. Actually, the loss of ownership is a very two-edged weapon.

    Jan 3, 2018 at 17:21

  • 8

    SBO sounds strange. I’ve always heard SSO (small string optimization)

    – phuclv

    Oct 4, 2019 at 4:33

  • @phu Sure; but strings are not the only thing you use the trick on.

    Oct 4, 2019 at 14:19

  • 1

    @phuclv SSO is just a specific case of SBO, which stands for small buffer optimization. Alternative terms are small data opt., small object opt., or small size opt..

    Apr 24, 2020 at 15:02

  • 1

    As a side note, char const*const* argv just shows how far stupidity and ambiguity can go in C++ code…

    Nov 28, 2021 at 21:45


One way that string_view improves performance is that it allows removing prefixes and suffixes easily. Under the hood, string_view can just add the prefix size to a pointer to some string buffer, or subtract the suffix size from the byte counter, this is usually fast. std::string on the other hand has to copy its bytes when you do something like substr (this way you get a new string that owns its buffer, but in many cases you just want to get part of original string without copying). Example:

std::string str{"foobar"};
auto bar = str.substr(3);
assert(bar == "bar");

With std::string_view:

std::string str{"foobar"};
std::string_view bar{str.c_str(), str.size()};
assert(bar == "bar");


I wrote a very simple benchmark to add some real numbers. I used awesome google benchmark library. Benchmarked functions are:

string remove_prefix(const string &str) {
  return str.substr(3);
string_view remove_prefix(string_view str) {
  return str;
static void BM_remove_prefix_string(benchmark::State& state) {                
  std::string example{"asfaghdfgsghasfasg3423rfgasdg"};
  while (state.KeepRunning()) {
    auto res = remove_prefix(example);
    // auto res = remove_prefix(string_view(example)); for string_view
    if (res != "aghdfgsghasfasg3423rfgasdg") {
      throw std::runtime_error("bad op");
// BM_remove_prefix_string_view is similar, I skipped it to keep the post short


(x86_64 linux, gcc 6.2, “-O3 -DNDEBUG“):

Benchmark                             Time           CPU Iterations
BM_remove_prefix_string              90 ns         90 ns    7740626
BM_remove_prefix_string_view          6 ns          6 ns  120468514


  • 5

    It’s great that you provided an actual benchmark. This really shows what can be gained in relevant use cases.

    Oct 19, 2016 at 17:58

  • 1

    @DanielKamilKozar Thanks for the feedback. I also think benchmarks are valuable, sometimes they change everything.

    Oct 19, 2016 at 18:02


There are 2 main reasons:

  • string_view is a slice in an existing buffer, it does not require a memory allocation
  • string_view is passed by value, not by reference

The advantages of having a slice are multiple:

  • you can use it with char const* or char[] without allocating a new buffer
  • you can take multiple slices and subslices into an existing buffer without allocating
  • substring is O(1), not O(N)

Better and more consistent performance all over.

Passing by value also has advantages over passing by reference, because aliasing.

Specifically, when you have a std::string const& parameter, there is no guarantee that the reference string will not be modified. As a result, the compiler must re-fetch the content of the string after each call into an opaque method (pointer to data, length, …).

On the other hand, when passing a string_view by value, the compiler can statically determine that no other code can modify the length and data pointers now on the stack (or in registers). As a result, it can “cache” them across function calls.