C++高性能Setter实现优化：为何性能不及C#？

嘿，这个问题很有代表性，我来帮你拆解背后的原因，以及为什么优化后性能能追上甚至反超。

一、初始C++代码的性能瓶颈 #

你最初的C++版本耗时175ms，而C#只有77ms，主要有三个核心原因：

1. Vector频繁扩容的隐性开销
   你一开始用的std::vector<std::shared_ptr<Person>>没有预分配容量，vector的默认扩容逻辑是每次容量不足时翻倍（比如从0→1→2→4→8...），999999次插入需要十几次扩容。每次扩容都要：

   • 分配更大的内存块
   • 把旧内存里的元素（shared_ptr）移动到新内存
   • 释放旧内存
     这些操作的累计开销非常大，而C#的List<T>虽然也会扩容，但在这种批量场景下，CLR的内存管理可能在扩容效率上暂时领先——不过这不是本质差距，你后来用reserve()直接预分配足够内存，这部分开销就完全消除了。

2. Shared_ptr的额外成本
   存储std::shared_ptr<Person>意味着每个Person对象都在堆上单独分配，还要维护引用计数（原子操作，虽然单次开销不大，但批量操作下会累积）。更关键的是，vector里存的是指针，这些指针指向的堆内存是分散的，会导致缓存命中率极低——CPU要频繁在不同内存地址间跳转，这对性能影响很大。而C#的List<Person>存的是托管对象引用，CLR的垃圾回收器会尽量把对象分配在连续的托管堆区域，缓存友好性更好。

3. 字符串处理的差异
   这是最容易被忽略的点：C#的字符串字面量会被**字符串池（String Intern Pool）**缓存，所以p.Name = "John Chester Doe"本质上只是把引用指向池里的同一个字符串对象，没有任何内存分配或字符拷贝。但你的C++代码里，每次调用setName(L"John Chester Doe")，都会从const wchar_t*构造一个新的std::wstring——这意味着每次都要分配内存、拷贝17个宽字符，999999次循环下来，这部分开销非常可观。

二、优化后性能追上的原因 #

你改用std::vector<Person>并调用reserve(999999)后，耗时降到75ms，正好命中了几个关键优化点：

• 消除扩容开销：reserve直接分配了能容纳100万个Person的连续内存，完全避免了扩容时的内存分配和元素移动。
• 提升缓存命中率：vector里的Person对象是连续存储的，CPU缓存可以一次性加载多个对象，访问速度大幅提升——这比C#的引用存储更有优势。
• 去掉shared_ptr的开销：直接存储对象，不需要维护引用计数，也省去了堆上单独分配每个Person的开销。

三、进一步优化的小技巧 #

如果想让性能再上一个台阶，可以试试这些：

1. 复用字符串对象
   提前构造好字符串常量，避免每次从字面量构造：

   const std::wstring kFixedName = L"John Chester Doe";
   // 循环内：
   vec.back().setName(kFixedName);
   

   这样每次赋值是std::wstring的拷贝（或者如果你的setName支持移动，也可以用std::move，但这里常量不能移动），比从const wchar_t*构造要高效得多。

2. 直接在构造时初始化Name
   给Person加一个带参数的构造函数，避免后续的赋值操作：

   class Person {
       std::wstring _name;
   public:
       Person(std::wstring name) : _name(std::move(name)) {}
       // 保留setName如果需要后续修改
   };
   

   然后循环里直接用emplace_back构造：

   vec.emplace_back(kFixedName);
   

   这样少了一次成员函数调用和赋值操作，效率更高。

3. 考虑用std::string代替std::wstring
   如果你的场景不需要宽字符，改用std::string可以减少内存占用（每个字符1字节而不是2字节），进一步提升缓存命中率。

内容的提问来源于stack exchange，提问作者shrpq