std::string_view 到底比 const std::string& 快多少？

Question

std::string_view 已进入 C++17，并且广泛建议使用它来代替 const std::string&。

其中一个原因是性能。

有人可以确切地解释std::string_view 在用作参数类型时比const std::string& 更快吗？ （假设在被调用者中没有复制）

Answer 1

它可以做的一件事是避免在从空终止字符串进行隐式转换的情况下构造std::string 对象：

void foo(const std::string& s);

...

foo("hello, world!"); // std::string object created, possible dynamic allocation.
char msg[] = "good morning!";
foo(msg); // std::string object created, possible dynamic allocation.

Answer 2

string_view 提高性能的一种方式是它允许轻松删除前缀和后缀。在幕后，string_view 可以只将前缀大小添加到指向某个字符串缓冲区的指针，或者从字节计数器中减去后缀大小，这通常很快。另一方面，当您执行 substr 之类的操作时，std::string 必须复制其字节（这样您将获得一个拥有其缓冲区的新字符串，但在许多情况下您只想获得原始字符串的一部分而不复制）。示例：

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

使用 std::string_view:

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

更新：

我写了一个非常简单的基准来添加一些实数。我用了很棒的google benchmark library。基准函数是：

string remove_prefix(const string &str) {
  return str.substr(3);
}
string_view remove_prefix(string_view str) {
  str.remove_prefix(3);
  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

Answer 3

std::string_view 在某些情况下更快。

首先，std::string const& 要求数据位于 std::string 中，而不是原始 C 数组、由 C API 返回的 char const*、由某些反序列化引擎生成的 std::vector<char> 等。格式转换避免了复制字节，并且（如果字符串比特定 std::string 实现的 SBO¹ 长）避免了内存分配。

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] );
}

在string_view 的情况下不进行任何分配，但如果foo 使用std::string const& 而不是string_view，则会出现这种情况。

第二个真正重要的原因是它允许在没有副本的情况下使用子字符串。假设您正在解析一个 2 GB 的 json 字符串 (!)²。如果将其解析为std::string，则每个存储节点名称或值的此类解析节点复制将原始数据从 2 gb 字符串复制到本地节点。

相反，如果您将其解析为std::string_views，则节点引用原始数据。这可以在解析期间节省数百万次分配并将内存需求减半。

你可以获得的加速简直是荒谬的。

这是一个极端情况，但其他“获取子字符串并使用它”的情况也可以通过string_view 产生不错的加速。

决定的一个重要部分是使用std::string_view 会失去什么。不算多，但也有。

您失去了隐式空终止，仅此而已。因此，如果将相同的字符串传递给所有需要空终止符的 3 个函数，则转换为 std::string 一次可能是明智的。因此，如果已知您的代码需要一个空终止符，并且您不希望从 C 风格的源缓冲区等提供字符串，则可以使用 std::string const&。否则采取std::string_view。

如果std::string_view 有一个标志，表明它是否为空终止（或更奇特的东西），它甚至会删除使用std::string const& 的最后一个理由。

在某些情况下，采用不带 const& 的 std::string 优于 std::string_view。如果您需要在调用后无限期地拥有字符串的副本，则按值获取是有效的。您要么处于 SBO 的情况下（并且没有分配，只需几个字符副本即可复制它），要么您可以将堆分配的缓冲区 移动 到本地 std::string .有两个重载 std::string&& 和 std::string_view 可能会更快，但只是很小，它会导致适度的代码膨胀（这可能会让你失去所有的速度提升）。

---

¹小缓冲区优化

² 实际用例。

Answer 4

有两个主要原因：

• string_view 是现有缓冲区中的一个切片，它不需要内存分配
• string_view 按值传递，而不是按引用传递

---

切片的好处是多方面的：

• 您可以将其与 char const* 或 char[] 一起使用，而无需分配新缓冲区
• 您可以将多个切片和子切片放入现有缓冲区，而无需分配
• 子字符串是 O(1)，而不是 O(N)
• ...

整体性能更好，更一致。

---

按值传递也比按引用传递有优势，因为别名。

具体来说，当你有std::string const& 参数时，不能保证引用字符串不会被修改。因此，编译器必须在每次调用不透明方法（指向数据、长度等）后重新获取字符串的内容。

另一方面，当通过值传递string_view 时，编译器可以静态确定没有其他代码可以修改现在堆栈（或寄存器）中的长度和数据指针。因此，它可以跨函数调用“缓存”它们。

Answer 5

std::string_view 基本上只是const char* 的包装。并且传递const char* 意味着与传递const string*（或const string&）相比，系统中的指针会少一个，因为string* 意味着类似：

string* -> char* -> char[]
           |   string    |

显然，为了传递 const 参数，第一个指针是多余的。

ps 不过，std::string_view 和 const char* 之间的一个实质性区别是 string_views 不需要以空值结尾（它们具有内置大小），这允许较长字符串的随机就地拼接。