Thank you for all the comments about the string_view performance! Last week, I got a lot of feedback on how to improve the initial string split code.

Have a look at how can we update the code and get some better performance.

Intro

Last week, I showed a few examples of string_view. Obviously, in most of the cases, string_view was much faster than the standard string. A view is a non-owning reference, so there's no need to copy the data - only [ptr, len] is needed to mark the referenced range. Moreover, string_view was added into the Standard Library because of the performance.

Maybe my string_view vs string tests were not needed because the results were too obvious?

As always, it's not that easy. Running benchmarks is hard, and sometimes results might be entirely unexpected.

For example, the last time one string implementation was faster than the string_view counterpart...

One possible reason why the member function is slower than the std::find_first_of is that the member method uses memchr. See this comment by "en-em".

The generic std::find_first_of can be fully inlined by the compiler, while the member function is not. It would be an interesting experiment to figure out exactly why the generic std:: function is faster than a member method. Is memchr that slow (At least in GCC implementation)?

The second improvement comes from JFT who also implemented the algorithms using pointers and not iterators. That also gave a lot of speed increase.

Another idea was that we might preallocate some space at the beginning — so that we have fewer vector reallocations. For example, we can assume each word is 5...6 words and then use .reserve(). While it works nicely, we might end up with a bit larger vector - and later you'd probably want to shrink_to_fit(). And in total, I've noticed that it doesn't bring much performance gain. Some more tests would be needed here.