文章插图

这是我利用前面说的加锁、rdtsc 等等去测函数调用和虚函数调用的额外开销的差异问题 ， 我测出来的一个结果：每次函数调用的开销本身大概是2.5个时钟周期 ， 虚函数调用的开销大概是4个时钟周期 ， 这两个开销本身的差异不大 。不过我们后面会提到 ， 虽然这看起来差异不大 ， 但实际上仍然有问题 ， 而且我这个测试实际上是有一点点问题的 ， 因为在测试当中很有可能你调用的函数会变热 ，  也就是说多次调用了 ， 就会在缓存里 ， 你每次执行就会性能比较高 ， 但实际情况下有可能不在缓存里 ， 这样的话性能差异就又会变大了 。但也有很多其他因素 ， 我们后面有个例子可以具体再看一下 。

文章插图

性能测试有两种方法 ， 前面说的就属于是右边这一种“插桩测试” ， 这实际上不是最优先的测试方法 ， 它适用于已经明确知道瓶颈在某个函数的情况下 ， 就盯着这个函数去测 ， 看看怎么样能够提高这个函数的性能 。一般来讲 ， 你在找瓶颈的时候会使用左边这种“采样测试” ， 采样测试一般需要编译器或者是操作系统来提供一些支持 。GCC 本身有个 gperftools ， 但用起来并不是特别方便 ， 一般我推荐是 Google 的 perftools 会好一点 。Linux 本身也有个 perf ， 这些都是比较好的采样测试的方式 ， 一般来讲比较推荐用采样测试来找出性能瓶颈点 ， 然后在后续的测试当中可以考虑用插桩测试来把你想要提高性能的那个函数的性能精确地测一下 ， 把它性能提高 。

文章插图

总体来讲 ， 我们要考虑90/10的规律 ， 也就是说我们优化的一定是在瓶颈上的一部分代码 ， 剩下的部分就可以不用去优化 ， 或者说等前面的优化完了再去优化 ， 因为我们需要考虑生产率和性能的权衡问题 。如果你把时间大量耗费在没有必要的优化上 ， 那你总体生产率就太低了 ， 有可能这个程序的性能反而提不上去 。所以再强调一遍：过早优化是万恶之源 。

文章插图


文章插图

视图类型是说某一个对象不拥有指向的资源 ， 一般来讲它只是指针加长度这样轻量的东西 。但它用起来比较方便 ， 我们利用 C++ 里面的一些构造和隐式转换可以很方便地使用视图 ， 同时可以对接口进行同一化处理 。只要你保证底层的数据一直存在 ， 那我们实际就可以使用指针加长度这样一个比较轻量级的对象来访问 。这样一个视图类型对象的复制开销为 O1 ， 所以做传参的时候拷贝这个或者新构造这样一个对象都比较方便 。我们常见的视图类型有 string_view ， 这是 C++ 17 里有的；然后 C++ 20里面会有span ， 或者你等不及 C++ 20 的话 ， 只要你使用 C++ 14 以上的版本 ， 可以用 gsl::span 。C++ 20 在 ranges 下面还有好多的视图 ， 这些视图用起来都非常方便 ， 而且性能还非常高 。这就是C++ 提供d的一种抽象方式 ， 来帮你解决一些性能问题 。

• 美甲培训学校如何
• 服装设计培训 服装设计师培训学校
• 学会计 会计培训学校机构
• 英语口语培训 口语培训课程
• 影视摄影师培训学校
• 职业培训 深圳职业培训学校
• 装饰培训机构 装饰设计培训哪里好
• sigill sigikid
• 广州美容学校推荐 广州美甲培训学校地址
• 西安计算机培训机构哪个最好 西安计算机培训学校有哪些