c – 在编码时考虑内存碎片:过早优化?

前端之家收集整理的这篇文章主要介绍了c – 在编码时考虑内存碎片:过早优化?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在使用C编写的大型服务器应用程序.该服务器需要运行可能几个月而不重新启动.碎片已经是一个怀疑的问题,因为我们的记忆消耗随着时间的推移而增加.到目前为止,测量是将私有字节与虚拟字节进行比较,并分析这两个数字的差异.

我的分裂的一般方法是把它分析.我有同样的思考其他事情的方式,如一般性能和内存优化.您必须通过分析和证明来备份变更.

我在代码审查或讨论中注意到很多,内存碎片是最早出现的一件事情.现在几乎就像现在有很大的恐惧,而且还有一个很大的举措提前“预防分裂”.请求代码更改似乎有利于减少或防止内存碎片问题.我倾向于不同意这些权利,因为他们似乎过早地优化了我.我会牺牲代码清洁/可读性/可维护性等.以满足这些变化.

例如,请使用以下代码

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?

还有一个巨大的推动,使用堆栈堆可能有可能.

有可能以这种方式抢先记忆碎片,还是简单的虚伪的安全感呢?

解决方法

如果您事先知道您需要低碎片,并且您已经预先测量了碎片是您实际的问题,并且您事先知道您的代码哪些部分相关,这还不成熟.性能是一个要求,但盲目优化在任何情况下都是坏的.

然而,优越的方法是使用无破片的自定义分配器,如对象池或内存竞技场,保证不会碎片化.例如,在物理引擎中,您可以使用内存竞技场进行所有每个刻度分配,并将其清空,这不仅非常快速(甚至比VS2010上的_alloca更快),而且还具有极高的内存效率和低碎片率.

猜你在找的C&C++相关文章