c++ - 编码 : Premature Optimization or not? 时考虑内存碎片

Question

我正在开发一个使用 C++ 编写的大型服务器应用程序。该服务器可能需要运行数月而不重新启动。碎片在这里已经是一个可疑的问题，因为我们的内存消耗会随着时间的推移而增加。到目前为止，测量是将私有(private)字节与虚拟字节进行比较，并分析这两个数字的差异。

我处理碎片化的一般方法是留待分析。我对一般性能和内存优化等其他事情也有同样的思考方式。您必须用分析和证明来支持更改。

我在代码审查或讨论期间注意到很多，内存碎片是最先出现的事情之一。几乎就像现在对它产生了巨大的恐惧，并且有一个提前“防止碎片化”的大倡议。请求的代码更改似乎有利于减少或防止内存碎片问题。我倾向于立即不同意这些，因为它们对我来说似乎是过早的优化。我会牺牲代码的清洁度/可读性/可维护性/等等。为了满足这些变化。

例如，拿下面的代码:

std::stringstream s;
s << "This" << "Is" << "a" << "string";

上面，stringstream 在这里进行的分配数量是未定义的，它可以是 4 个分配，或者只是 1 个分配。所以我们不能仅基于此进行优化，但普遍的共识是要么使用固定缓冲区，要么以某种方式修改代码以潜在地使用更少的分配。我真的不认为 stringstream 在这里扩展自己是内存问题的一个巨大贡献者，但也许我错了。

对上述代码的一般改进建议如下:

std::stringstream s;
s << "This is a string"; // Combine it all to 1 line, supposedly less allocations?

还有一个巨大的插入力，即尽可能在堆上使用堆栈。

是否可以通过这种方式抢占内存碎片，或者这仅仅是一种错误的安全感？

Answer 1

如果您事先知道您需要低碎片化并且您已经预先衡量碎片化对您来说是一个实际问题并且您就不是过早的优化提前知道代码的哪些部分是相关的。性能是必需的，但盲目优化在任何情况下都是不好的。

然而，更好的方法是使用无碎片的自定义分配器，如对象池或内存区域，这样可以保证没有碎片。例如，在一个物理引擎中，你可以为所有的 per-tick 分配使用一个 memory arena 并在最后清空它，这不仅快得离谱(甚至比 VS2010 上的 _alloca 还快)而且极高的内存效率和低碎片。