【问题标题】:Why is std::string_view faster than const char*?为什么 std::string_view 比 const char* 快?
【发布时间】:2020-02-01 09:37:26
【问题描述】:

还是我在测量其他东西?

在这段代码中,我有一堆标签 (integers)。每个标签都有一个字符串表示(const char*std::string_view)。 在循环堆栈值被转换为相应的字符串值。这些值被附加到预先分配的字符串或分配给数组元素。

结果显示std::string_view的版本比const char*的版本稍快。

代码:

#include <array>
#include <iostream>
#include <chrono>
#include <stack>
#include <string_view>

using namespace std;

int main()
{
    enum Tag : int { TAG_A, TAG_B, TAG_C, TAG_D, TAG_E, TAG_F };
    constexpr const char* tag_value[] = 
        { "AAA", "BBB", "CCC", "DDD", "EEE", "FFF" };
    constexpr std::string_view tag_values[] =
        { "AAA", "BBB", "CCC", "DDD", "EEE", "FFF" };

    const size_t iterations = 10000;
    std::stack<Tag> stack_tag;
    std::string out;
    std::chrono::steady_clock::time_point begin;
    std::chrono::steady_clock::time_point end;

    auto prepareForBecnhmark = [&stack_tag, &out](){
        for(size_t i=0; i<iterations; i++)
            stack_tag.push(static_cast<Tag>(i%6));
        out.clear();
        out.reserve(iterations*10);
    };

// Append to string
    prepareForBecnhmark();
    begin = std::chrono::steady_clock::now();
    for(size_t i=0; i<iterations; i++) {
        out.append(tag_value[stack_tag.top()]);
        stack_tag.pop();
    }
    end = std::chrono::steady_clock::now();
    std::cout << out[100] << "append string const char* = " << std::chrono::duration_cast<std::chrono::microseconds>(end - begin).count() << "[µs]" << std::endl;

    prepareForBecnhmark();
    begin = std::chrono::steady_clock::now();
    for(size_t i=0; i<iterations; i++) {
        out.append(tag_values[stack_tag.top()]);
        stack_tag.pop();
    }
    end = std::chrono::steady_clock::now();
    std::cout << out[100] << "append string string_view= " << std::chrono::duration_cast<std::chrono::microseconds>(end - begin).count() << "[µs]" << std::endl;

// Add to array
    prepareForBecnhmark();
    std::array<const char*, iterations> cca;
    begin = std::chrono::steady_clock::now();
    for(size_t i=0; i<iterations; i++) {
        cca[i] = tag_value[stack_tag.top()];
        stack_tag.pop();
    }
    end = std::chrono::steady_clock::now();
    std::cout << "fill array const char* = " << std::chrono::duration_cast<std::chrono::microseconds>(end - begin).count() << "[µs]" << std::endl;

    prepareForBecnhmark();
    std::array<std::string_view, iterations> ccsv;
    begin = std::chrono::steady_clock::now();
    for(size_t i=0; i<iterations; i++) {
        ccsv[i] = tag_values[stack_tag.top()];
        stack_tag.pop();
    }
    end = std::chrono::steady_clock::now();
    std::cout << "fill array string_view = " << std::chrono::duration_cast<std::chrono::microseconds>(end - begin).count() << "[µs]" << std::endl;
    std::cout << ccsv[ccsv.size()-1] << cca[cca.size()-1] << std::endl;

    return 0;
}

我的机器上的结果是:

Aappend string const char* = 97[µs]
Aappend string string_view= 72[µs]
fill array const char* = 35[µs]
fill array string_view = 18[µs]

Godbolt 编译器浏览器网址:https://godbolt.org/z/SMrevx

UPD:更准确的基准测试后的结果(500 次运行 300000 次迭代):

Caverage append string const char* = 2636[µs]
Caverage append string string_view= 2096[µs]
average fill array const char* = 526[µs]
average fill array string_view = 568[µs]

神箭网址:https://godbolt.org/z/aU7zL_

所以在第二种情况下const char* 比预期的更快。第一种情况在答案中进行了解释。

【问题讨论】:

  • 从反汇编来看,const char* 变体似乎在运行时调用了 strlen。我认为编译器可以在 string_view 的编译期间执行此操作。
  • 这里没有理由使用std::endl;无论如何,您都可以将 \n 作为您正在打印的字符串的一部分。打印在定时区域之外,因此无论是否发生刷新都应该没问题,但如果输出流向管道,cout / stdio 缓冲区可能足够大,以至于直到最后都不必进行刷新。在每个定时部分之间不进行系统调用是一件好事。

标签: c++ optimization benchmarking string-view


【解决方案1】:

很简单,因为std::string_view 传递了长度,并且您不必在需要新字符串时插入空字符。 char* 必须每次搜索结尾,如果你想要一个子字符串,你可能必须复制,因为你需要在子字符串的末尾有一个空字符。

【讨论】:

  • 用数组做becnhmark怎么样?它不只是一个复制到数组的指针。还是它引用的字符串文字也被复制了?
  • @uni:如果你先对另一个进行基准测试,这些数字会改变吗?您的总基准测试结束得如此之快,以至于 CPU 可能会在那时左右加速到最大涡轮增压。或者第一个数组比第二个数组支付更多的页面错误成本。 TL:DR:你的那部分结果可能归结于幼稚的微基准测试方法。
  • @uni: 或者是真的;我尝试反转它们并在 Godbolt 上运行仍然显示填充数组 string_view = 19[µs],而 const char* 为 61[µs]。 godbolt.org/z/MyUxqE。循环循环基本上是等效的,假设它们永远不会落入调用operator delete 的部分。 (当然,字符串视图对象为 16 字节宽,并使用 movdqa / movaps 获取副本)。 IDK,必须使用性能计数器在本地尝试,或者单步查看是否发生删除调用。增加迭代次数会降低一些差异率:godbolt.org/z/jvM8Cr
  • @PeterCordes 我听从了您的建议,增加了迭代次数和基准运行时间,以在 500 次运行中获得平均时间。以下是结果:迭代 10000 50000 100000 200000 300000 string_view 17 87 183 368 588 const char* 17 88 177 353 526 delta 0 -1 6 15 62 在这种情况下,差异很小,const char* 现在更快
  • @uni:这更有意义。可能const char* 对于大迭代计数更快,因为它更小,而这些大尺寸意味着更大的数组开始出现 L1 甚至 L2 缓存未命中。 (现代 x86-64 可以像复制 16 字节对象一样快地复制 8 字节对象,尤其是当它们对齐时。)仍然不确定是什么在没有重复循环的情况下减慢了小尺寸。
【解决方案2】:

std::string_view 出于实际目的归结为:

{
  const char* __data_;
  size_t __size_;
}

该标准实际上以秒为单位指定。 24.4.2 这是一个指针和大小。它还指定某些操作如何与字符串视图一起使用。最值得注意的是,每当您与std::string 交互时,您都会调用将大小作为输入的重载。因此,当您调用 append 时,这归结为两个不同的调用:str.append(sv) 转换为 str.append(sv.data(), sv.size())

显着的区别在于您现在知道append 之后字符串的大小,这意味着您还知道是否必须重新分配内部缓冲区,以及你必须做到多大。如果您事先不知道大小,您可以开始复制,但std::stringappend 提供强力保证,因此出于实际目的,大多数库可能会预先计算长度和所需的缓冲区,尽管从技术上讲,如果您没有成功完成,也可以只记住旧大小并在之后擦除所有内容(怀疑有人这样做,尽管它可能是对字符串的局部优化,因为销毁是微不足道的)。

【讨论】:

    【解决方案3】:

    这可能是由于 string_view 具有字符串值的大小。 “const char*”没有关于大小的信息,必须定义它。

    【讨论】:

      猜你喜欢
      • 2017-02-28
      • 2021-01-20
      • 2014-10-24
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2022-01-06
      • 1970-01-01
      相关资源
      最近更新 更多