【发布时间】：2014-04-26 14:08:29
【问题描述】：
我正在处理一个较旧的 MFC/C++ 项目，该项目使用 MFC 的 CString 类来处理字符串来解析大型文本文件。我注意到在解析过程中，有很多小部分添加到整个大型 CString 对象中：
//'strContainer' = CString
//'tag' = CString of a much smaller size
strContainer += L"<" + tag + L">";
当strContainer 变量达到某个较大的大小时，上面的运算符似乎会降低 CString 的整体性能。我认为这是因为+= 运算符经常重新分配内存。
所以我很好奇，有什么办法可以改善这一点吗？
PS1。我不知道预先分配结果字符串的大小。
PS2。由于项目本身的复杂性，我必须坚持使用 CString。 （或者，我无法切换到 Boost 或其他更新的实现。）
【问题讨论】：
-
实际上，
+=可能是最快的部分。性能问题可能是临时工的+。因此，请执行三遍+=，看看是否会有所不同。 -
@MooingDuck：衡量这种性能的问题在于，单个操作员本身不会引起人类注意。当我在解析方法中运行数千个它们时，它就会变得可见。无论哪种情况，我都很肯定它是执行内存重新分配的
CString运算符之一。我总结它是因为它的性能随着CString变量的大小呈指数下降。 -
即使您无法预先分配最佳金额，您仍然可以预先分配足够的金额来满足您的大部分情况。与第一次编写程序时相比，内存问题可能要少得多。
-
这段代码编译是否经过优化（不是调试模式？）。我编写了处理非常大的字符串的代码（诚然不是 CString，但我怀疑它效率低下）。在调试版本中，由于各种额外的检查，几乎可以肯定它非常慢。
-
@c00000fd：只需在开始追加之前调用
Preallocate，并为其提供一个足以容纳 95% 数据的数字。超级容易。 （另外 5% 会像以前一样重新分配，但通常只分配一次，而不是 10 次）
标签： c++ performance mfc cstring