跟我学C++中级篇——编译期和运行时的性能处理分析

最新推荐文章于 2026-06-16 20:19:21 发布
原创 最新推荐文章于 2026-06-16 20:19:21 发布 · 1.1k 阅读 · 25 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
标签
#c++

一、性能的处理

开发者在对性能的优化过程中，一般更多的是在运行时进行处理。比如重用内存或减少CPU的占用等。但其实有不少的性能的优化其实是可以在编译期展开的，最常见的就是一些算法的展开可以在编译期直接展开计算。特别是随着C++新标准对编译期的支持处理越来越广泛（比如constexpr的引入），使得很多需要复杂的技术（如模板或元编程等）的场景下，也可以转到编译期优化。一般来说，可以把优化分成两类，一类是运行时的优化；另外一类是编译期的优化。当然，这二者不会是互斥的，开发者可以根据实际的情况确定应用哪种或二者一起使用。

二、运行时的性能及相关问题

比如有一个状态分发的应用场景，对于开发者来说，可能有以下几种方法来处理：

  1. 使用多态形成动态分发
  2. 强制转换状态，然后使用条件语句（if或switch等）来处理
  3. 使用表（map之类），然后绑定自动跳转
    上述的几种方法，均是在运行时进行处理的，它们的实现有很多种方式（随机组合），但本质基本都类似。正如前面分析过if和switch的性能的问题，只要固定在某种具体的解决方式下，其基本的性能上下限就确定了。以上述三种情况为例，分析一下其特点：
  4. 多态处理
    编写复杂度较高；虚函数的应用明显的会降低分发的性能，且可能需要较多的内存开销；而且其作为基于运行时的动态联编，基本也无法在编译期进行优化；最重要的是，其没有办法使用缓存
  5. 使用条件语句
    应用相对复杂，特别是在多条件处理时；可能需要强制转换，导致数据类型不安全；条件语句的处理不当可能引发性能的降低（如使用大量的if elseif）；扩展不方便，容易引发各种误判和漏判等情况；很多情况下对分支预测比较麻烦；对缓存的使用一般（如果分支预测准确则会大幅提高）；对编译期优化支持也一般
  6. 表处理
    表处理无论是switch内部最终形成的表，还是使用map等形成的表，性能都非常好；对缓存的支持也相对友好；编译期可以使用一些常量进行优化；但其可能对开发者的要求相对高一些。

三、编译期的优势

在分析了运行时的一些场景后，其实有些解决方式已经呼之欲出。比如上面的表处理的使用常量表达式进行优化 ，其实就是可以把一些运行时的处理转到编译期。在早期的C++编程中，编译期处理主要有两种情况：

  1. 宏处理
    这种处理方式简单的应用情况下还好，复杂的情况几乎不是开发者能够短时间内掌握的，无论是学习成本还是应用成本都相当高。典型的就是微软的MFC中的例子。
  2. 模板特别是模板的元编程
    多态有动多态和静多态。模板就可以认为是静多态(比如前面提到的CRTP)。还有包括分析过的SFINAE技术进行分发都可以实现具体的功能。这些技术最大的问题不是各种细节的问题而复杂。大多数的C++程序员可能根据没接触模板编程的实际应用，更不用提元编程技术了。

在C++11后，陆续推出了更多的对编译期友好的支持接口。如 constexpr,if constexpr，consteval,if consteval,concept,变量模板，非类型模板参数，编译期容器，内联变量，折叠表达式以及反射等。这里面其实最容易为大家理解和接受的就是constexpr的应用。看一个简单简便的例子：

template <typename T>
auto to_string(T t) {
   if constexpr(std::is_integral<T>::value) {
     return std::to_string(t);
   } else {
     return t;
   }
 }

上面的这些应用，包括if consteval等的示例代码，在前面写过很多，有兴趣的可以回去头去看一看，可以更好的加深一下印象。

四、标准库中典型的用法std::visit

在STL中有一个类型接口就体现了这种编译期优化的情况，它就是std::visit。其核心的特点在于：

  1. 静多态（编译期多态 ）
  2. 表机制的访问
  3. 内联优化
  4. 缓存友好
  5. 死分支消除和常量传播处理

来看一下其内部的实现：


  template<typename _Visitor, typename... _Variants>
    constexpr __detail::__variant::__visit_result_t<_Visitor, _Variants...>
    visit(_Visitor&& __visitor, _Variants&&... __variants)
    {
      namespace __variant = std::__detail::__variant;

      if ((__variant::__as(__variants).valueless_by_exception() || ...))
	__throw_bad_variant_access("std::visit: variant is valueless");

      using _Result_type
	= __detail::__variant::__visit_result_t<_Visitor, _Variants...>;

      using _Tag = __detail::__variant::__deduce_visit_result<_Result_type>;

      if constexpr (sizeof...(_Variants) == 1)
	{
	  using _Vp = decltype(__variant::__as(std::declval<_Variants>()...));

	  constexpr bool __visit_rettypes_match = __detail::__variant::
	    __check_visitor_results<_Visitor, _Vp>(
	      make_index_sequence<variant_size_v<remove_reference_t<_Vp>>>());
	  if constexpr (!__visit_rettypes_match)
	    {
	      static_assert(__visit_rettypes_match,
			  "std::visit requires the visitor to have the same "
			  "return type for all alternatives of a variant");
	      return;
	    }
	  else
	    return std::__do_visit<_Tag>(
	      std::forward<_Visitor>(__visitor),
	      static_cast<_Vp>(__variants)...);
	}
      else
	return std::__do_visit<_Tag>(
	  std::forward<_Visitor>(__visitor),
	  __variant::__as(std::forward<_Variants>(__variants))...);
    }
      template<typename _Result_type, typename _Visitor, typename... _Variants>
    constexpr decltype(auto)
    __do_visit(_Visitor&& __visitor, _Variants&&... __variants)
    {
      // Get the silly case of visiting no variants out of the way first.
      if constexpr (sizeof...(_Variants) == 0)
	{
	  if constexpr (is_void_v<_Result_type>)
	    return (void) std::forward<_Visitor>(__visitor)();
	  else
	    return std::forward<_Visitor>(__visitor)();
	}
      else
	{
	  constexpr size_t __max = 11; // "These go to eleven."

	  // The type of the first variant in the pack.
	  using _V0 = typename _Nth_type<0, _Variants...>::type;
	  // The number of alternatives in that first variant.
	  constexpr auto __n = variant_size_v<remove_reference_t<_V0>>;

	  if constexpr (sizeof...(_Variants) > 1 || __n > __max)
	    {
	      // Use a jump table for the general case.
	      constexpr auto& __vtable = __detail::__variant::__gen_vtable<
		_Result_type, _Visitor&&, _Variants&&...>::_S_vtable;

	      auto __func_ptr = __vtable._M_access(__variants.index()...);
	      return (*__func_ptr)(std::forward<_Visitor>(__visitor),
				   std::forward<_Variants>(__variants)...);
	    }
	  else // We have a single variant with a small number of alternatives.
	    {
	      // A name for the first variant in the pack.
	      _V0& __v0
		= [](_V0& __v, ...) -> _V0& { return __v; }(__variants...);

	      using __detail::__variant::_Multi_array;
	      using __detail::__variant::__gen_vtable_impl;
	      using _Ma = _Multi_array<_Result_type (*)(_Visitor&&, _V0&&)>;

#ifdef _GLIBCXX_DEBUG
# define _GLIBCXX_VISIT_UNREACHABLE __builtin_trap
#else
# define _GLIBCXX_VISIT_UNREACHABLE __builtin_unreachable
#endif

#define _GLIBCXX_VISIT_CASE(N)						\
  case N:								\
  {									\
    if constexpr (N < __n)						\
      {									\
	return __gen_vtable_impl<_Ma, index_sequence<N>>::		\
	  __visit_invoke(std::forward<_Visitor>(__visitor),		\
			 std::forward<_V0>(__v0));		\
      }									\
    else _GLIBCXX_VISIT_UNREACHABLE();					\
  }

	      switch (__v0.index())
		{
		  _GLIBCXX_VISIT_CASE(0)
		  _GLIBCXX_VISIT_CASE(1)
		  _GLIBCXX_VISIT_CASE(2)
		  _GLIBCXX_VISIT_CASE(3)
		  _GLIBCXX_VISIT_CASE(4)
		  _GLIBCXX_VISIT_CASE(5)
		  _GLIBCXX_VISIT_CASE(6)
		  _GLIBCXX_VISIT_CASE(7)
		  _GLIBCXX_VISIT_CASE(8)
		  _GLIBCXX_VISIT_CASE(9)
		  _GLIBCXX_VISIT_CASE(10)
		case variant_npos:
		  using __detail::__variant::__variant_idx_cookie;
		  using __detail::__variant::__variant_cookie;
		  if constexpr (is_same_v<_Result_type, __variant_idx_cookie>
				|| is_same_v<_Result_type, __variant_cookie>)
		    {
		      using _Npos = index_sequence<variant_npos>;
		      return __gen_vtable_impl<_Ma, _Npos>::
			__visit_invoke(std::forward<_Visitor>(__visitor),
				       std::forward<_V0>(__v0));
		    }
		  else
		    _GLIBCXX_VISIT_UNREACHABLE();
		default:
		  _GLIBCXX_VISIT_UNREACHABLE();
		}
#undef _GLIBCXX_VISIT_CASE
#undef _GLIBCXX_VISIT_UNREACHABLE
	    }
	}
    }

看上去是不是很吓人，其实它的实现还是通过表的查找跳转来实现，看一下简化的代码：

template<typename Visitor, typename Variant>
auto visit_impl(Visitor&& vistor, Variant&& var) {
    static constexpr std::array<void(*)(Visitor&&, Variant&&), variant_size_v<Variant>> jump_table = {
        [](Visitor&& vistor, Variant&& var) { 
            std::invoke(std::forward<Visitor>(vistor), 
                       std::get<0>(std::forward<Variant>(var))); 
        },
        [](Visitor&& vistor, Variant&& var) { 
            std::invoke(std::forward<Visitor>(vistor), 
                       std::get<1>(std::forward<Variant>(var))); 
        },
        // ... gen lambda
    };
    

    return jump_table[var.index()](
        std::forward<Visitor>(vistor), 
        std::forward<Variant>(var)
    );
}

其实对于绝大多数的开发者来说，看看上面的代码即可，不必纠结深入其中。意义确实不大。
通过上面的分析，其实可以清楚的看到，std::visit由于采用了编译期的静态展开，基本可以实现内联调用，这就意味着直接函数调用将会显著的提高性能；同时，由于其采用了缓存友好的数据内存分布，也可以提高数据操作的效率。
当然，看上面的代码也明白，std::visit的缺点同样明显，不管是模板还是内联，都可能造成代码的膨胀，从而引发各种问题；另外一个就是造成了编译速度可能会下降。技术也是平衡的，这也是体现出来的一个例子。

五、问题和建议

反复谈过的一个问题就是，不要抓住一只羊猛薅。编译期优化往往带来另外一个问题，就是编译期的运行时间增加了。当然这对于小规模的优化还好，如果大规模特别是把一些计算转到编译编译期，往往会带来很长的编译时间等待，这就需要开发者认真平衡的考虑了。常见的编译期遇到的问题有：

  1. 在编译期引入过长的循环
  2. 多层嵌套或递归调用
  3. 类型的不确定性转换
  4. 静态多态
  5. 编译期计算

其实在使用编译器提高性能时，还有不少的细节需要处理。而且C++标准这方面也是在陆续完善的过程中，这就需要开发者自己动态的调整设计理念和引入更多的优秀的设计思想。编译期性能优化经常应用的场景主要有：

  1. 类型安全的状态（机）的控制
  2. 元数据的配置
  3. 条件语句的处理

六、总结

开发者的武器有很多种，不要习惯于哪种便一直用哪种。吃饭还讲究个时不时换个品味呢？开发者要善于和敢于接受新的技术点和知识，更要善于将它们应用到实际的开发中去。在实际的场景中检测应用的是否合理，是否有进一步优化的余地。如此在实践中不断的思考和分析，技术的提高是一个自然而然的过程。

跟我学C++中级篇——返回值优化
fpcc的专栏
08-10 1558
在开发者编写代码的过程中，很多函数需要返回值的。如果只是简单的返回一个基础类型值，即使有一些浪费，这些浪费在整体的程序运行中其实影响还是相当小的。但当开发者自定义一些数据结构或者字符串等的返回时，就有可能出现多次拷贝的现象。这样的运行成本可能就相当大了。开发者在早期的编译期环境中，可能需要一些具体的技巧来处理这些返回值，但在越来越优秀的编译器加持下，返回值优化的手段从开发者不断的向编译期转移。这和前文（跟我学C++中级篇——临时对象）分析过的临时对象有着很大的联系，可一并参考学习分析。
跟我学C++中级篇——对类const关键字的分析说明
fpcc的专栏
01-07 770
本文对比分析了C++中四个相似关键字const、constexpr、consteval和constinit的区别与应用场景。const用于运行时只读控制，constexpr支持编译期计算，consteval强制编译期求值函数，constinit确保静态变量的编译期初始化。文章通过示例代码展示了各关键字的具体用法，并指出应根据实际需求选择合适的关键字，同时考虑C++标准版本差异，以编写安全高效的代码。重点在于理解各关键字在编译期与运行期行为上的差异，以及它们在接口约束、编译期计算和初始化控制等场景下的适用性。
跟我学C++中级篇——循环展开的分析
fpcc的专栏
12-14 639
本文探讨了循环展开（loop unrolling）这一编译器优化技术。循环展开通过减少条件分支和流水线停顿来提升性能，适用于迭代次数少且计算量大的短循环。文章介绍了手动和自动两种展开方式，分析了其性能提升原理（减少指令跳转、提高缓存命中率），同时也指出了过度展开可能导致代码膨胀、寄存器耗尽等缺点。最后介绍了模板元编程、常量表达式等高级展开方法，并建议在现代开发中优先考虑编译器优化和SIMD并行技术。循环展开需要根据实际情况谨慎使用，通过性能测试验证优化效果。
跟我学c++中级篇——zero overhead abstraction
fpcc的专栏
12-26 2574
对零成本抽象进行一些基本的说明
C++性能测试工具——gperftools的安装
热门推荐
fpcc的专栏
02-02 1万+
一、软件安装说明 gperftools的安装有再从种方式，一种是源码方式，一种是直接安装模式。这里源码安装模式，原因是使用直接安装模式比较简单。安装此软件需要先安装libunwind这个软件，所以这里需要通过源码方式安装libunwind，否则会报一个警告：“configure: WARNING: No frame pointers and no libunwind. Using experimental backtrace capturing via libgcc.Expect crashy cpu pr
cmake对编译器版本和库依赖的问题
fpcc的专栏
10-21 1万+
cmake对编译器版本和库依赖的问题 一、介绍 最近在编译Wasm的几个相关工具时，其使用的是cmake工具，一般来说，开源的软件的编译文档会写的相当清楚，而且开源软件为了让客户体验方便，一般编译的步骤和依赖的相关工具和库，都会尽量整合到一起，防止因为无谓的原因导致编译问题影响软件的整体下载应用。 在编译相关的工具过程中，确实发现很多都基本可以做到两三到命令即可完成编译，也不需要下载过多的依赖。但...
多核和多CPU编程——并行计算的加速比
fpcc的专栏
03-29 1万+
一、并行计算的衡量 并行计算和串行计算到底哪个好，或者说并行计算中哪个优哪个劣？这需要有一些衡量的标准： 通过上述的参数的对比，可以在整体上有一个性能的参考。 二、加速比（Speedup） 加速比就是指并行计算比传统的串行执行速度提高了多少倍。即： 加速比（Sn）=单处理器最优算法串行时间/多核并行计算时间 它涉及到两个定律： 1、Amdahl定律 Gene Amdahl于1967年提出了这个定律，用于在并行计算相对于最优串行算法在性能上提升的理论上的最大值： 上面的主要说明如下： n: 并行系统中处理
C++性能测试工具gprof和gperftools基础
fpcc的专栏
01-09 1万+
一、程序的性能及测试 软件的性能指的是软件所能满足的性能指标，主要包括压力测试指标和负载测试指标。软件的性能测试是通过模拟实际生产的业务压力和具体环境组合，来测试系统的性能是否达到软件设计的性能指标。在c++的应用程序里，天然的要求就是高性能，这也是对c++性能测试的一个痛点。目前常见的大型软件，用c\c++实现的非常多，比如数据中的MySql，内存型数据库Redis，微信和QQ，损伤系统等等。 掌握常见的c++性能测试工具，对于c\c++开发人员来说，是一项必备的技能。它能够帮助开发者，快速发现大型应用程
C++性能测试工具gprof安装和应用
fpcc的专栏
02-26 9928
一、gprof的安装和说明 在前面谈过了gperftools的安装，今天来看一下gprof的安装。虽然说gperftools安装比较复杂，但是gprof就好说了，因为只要你的机器上装有GCC，那么自然就带了这个软件。如果没有的话，就按照以下的方法安装一下新的gcc即可。不过一般来说，系统都会自带相对最新的gcc，这个不用太担心。 https://blog.csdn.net/fpcc/article/details/99698783?ops_request_misc=%257B%2522request%255
c++性能测试工具——gperftools的应用
fpcc的专栏
02-12 9191
一、应用场景 性能测试的应用场景除了大规模计算、寻找瓶颈之外，其实对于不停服的服务端程序（包括Web服务和CS服务端等），更具有实战意义。在此类的实际场景中，经常存在以下几个问题： 1、服务端调优，需要找到性能瓶颈，而往往这种瓶颈并不是随时出现，而是随机出现的。 2、问题异常的发现，比如偶尔会有突然的报警或者CPU内存等异常升高。 3、多方比较，与同类型或者友商类似软件的性能比较分析 4、设计验证，也就是开发架构时的设想与实际上线后有何差别，差别有多大。 这些都需要一些量化指标，而这些量化指标，就需要通过测
跟我学c++高级篇——反射
fpcc的专栏
05-01 7955
其实反射也可以放到模板元编程中来进行分析，但是为了更好的讲解一些c++的高级特性，还是把它分离了出来。c++的许多高级的特性，在国内的大多数应用场景上，其实是应用不到的。原因是，这些高级特性大多是在基础库支持或者基础软件上才用的。而这恰恰是国内的软肋。知已知彼，百战不殆。看到有什么不足，才能更好的补齐它。共同努力！
跟我学c++高级篇——反射的基本实现方式
fpcc的专栏
05-21 7015
太极生两仪，两仪有四象，四象生八卦。正如道家所说一生二，二生三，三生万物。学习也要从简单抓起，然后反复不停的在此基础上锤练，不断的向上发展，让整个体系愈发的完整并且向着新的未知不断的探索。对个人来说，技术的精湛莫不如是。对技术本身来说，更是如此。要站在巨人的肩膀上，不断的向前看，看向更高。
跟我学c++初级篇——transform用法
fpcc的专栏
11-25 6943
对标准库的transform函数进行实例说明
静态或者全局智能指针使用的注意几点
fpcc的专栏
02-07 6296
静态或者全局智能指针使用的注意几点 在C++11普及开始后，智能指针才真正的被广大的C++程序员使用，当然一些高手还有大牛还是非常轻视智能指针的，咱们不谈那个。今天只谈一谈智能指针的全局化和静态化后需要注意的几点： 一、全局化或者静态化 全局化是指这个智能指针变量是全局的，全局的智能指针变量，会产生什么样的问题呢，其实就是最担心的重复释放，然后引起程序的崩溃。最典型的就是如下： std::
C++20中的三路比较运算符
fpcc的专栏
10-11 5957
一、operator<=> 三路比较运算符也是一个c++20新提供的一个功能，网上有的人叫“航天飞机运算符”也有的叫“宇宙飞船运算符”，知道啥意思就行。在以前的c++编程中，实现基本类型的比较功能是由标准语法直接提供的，但在实际的编程中，经常会遇到这样一些问题，封装好的对象（类和结构体对象）也会出现一些比较的要求，这时候儿，一般会通过重载某个运算符来实现特定的对象的比较。而在c++20中提供的这个三路比较运算符，会默认生成一系列的比较运算符，如果默认生成的语义不符合自己的标准，那么可以自定义其
C++的实际应用
fpcc的专栏
05-30 5880
前言 首先说明，这是一篇务虚的文章，没有什么技术理论和思想，也没有什么实际技术的分析和学习，只是一篇从个人角度阐述看法的文章。 一、c++的面临的环境 c++从诞生之初，其实就是代表着一种编程思想的进步，这是从面向结构编程向面向对象编程的一种跨越。但是这种跨越不是完全的、彻底的。这也可以理解，所以c++同时支持了二者的实际应用场景。 但是，随着一些更加高级的语言的出现，如Java、C#、Python、Golang等，c++的应用在很多领域飞速降低，特别是在近20年来大爆发的互联网（包括移动互联网）上，c++
死锁和活锁
fpcc的专栏
04-15 5669
一、多线程的资源竞争 多线程编写的复杂度其实就是体现在资源的竞争控制上，这个在以前的文章中反复提到过。资源竞争主要是两种情况，数据竞争和执行任务竞争。通过前面的文章介绍可以知道，锁可以解决这些问题，但如何更好的处理竞争问题并达到最优，这就需要策略和算法了。包括提到的无锁编程，其实也是一种解决的策略。 无论是在单核亦是多核的情况下，资源的竞争总是不可避免的，所以对资源的控制就是需要认真对待的一个问题。 二、死锁 所谓死锁，其实就是“集合中的每一个进程都在等待只能由本集合中的其他进程才能引发的事件，那么该组进程
C++中两个宏__PRETTY_FUNCTION__和__FUNCSIG__的应用
fpcc的专栏
05-27 5588
这种东西很简单，但也很实用。如果利用好了，可以实现一些技巧性的东西，比如上面的B站的那个视频中的应用。同时，也正是这些基础性的东西，反而更可以清楚的看出来不同的标准，不同的编译器，同一标准的不同时代的演进，让开发者可以更明白其中发展的过程而不至于大脑中一片乱乎乎的东西。大道至简，越是简单的东西，大多数人更容易接受。然后能不能自己外延，就看个人的本事了。
多核和多CPU编程——基本模式和库
fpcc的专栏
03-24 5051
一、基本模式 1、MPI MPI(Message Passing Interface)消息传递接口是MPI论坛发布的一个支持C/C++/Fortran库。属于一种消息传递编程模式，它提供了一种与平台无关的消息传递程序标准。它主要有三种实现：mpich、chimp 和lam。这种模型适应性好，无论是多核、多CPU还是分布式集群都可以使用。缺点是复杂的进程通信导致对开发者的要求较高，而且需要进行通信间的控制。 2、OpenMP OpenMP(Open Multi Processing)是由Open ARB发布的
分享如何实现Qt 高级开发 015：C++ 原生实现信号槽机制
最新发布
2401_85049165的博客
06-16 202
本文介绍了如何在C++中不依赖Qt框架原生实现信号槽机制。通过使用std::function和模板类，作者构建了Signal类来处理信号连接、发射和断开操作，并支持普通函数和成员函数作为槽。文章还讨论了线程安全和性能优化方案，包括使用互斥锁保护共享资源。这种实现方式保持了信号槽松耦合的特性，同时避免了Qt依赖，为C++开发者提供了一种轻量级的事件驱动编程方案。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值