我有一台服务器在 24 小时内不断向集合中添加新项目。元素不会在 24 周期内被删除，只会不断插入新元素。
然后在周期结束时，该集合被清除，并且新元素开始再次添加 24 小时。
您认为快速池分配器在这里是否有用，可以重用内存并可能有助于碎片化？
该集合增长到大约 100 万个元素。每个元素大约 1k。
问问题
1419 次
1 回答
2
这是极不可能的……但你当然可以在你的程序中自由地测试它。
对于该大小和分配模式的集合（更多！更多！更多！+增长！增长！增长！），您应该使用向量数组。只需将其保存在连续的块中，reserve()当它们被创建时，您就不需要重新分配/调整大小或浪费空间和带宽遍历列表。vector 将最适合您的内存布局，其中包含这么大的集合。不是一个大向量（调整大小需要很长时间），而是几个向量，每个向量代表块（理想的块大小可能因平台而异——我将从每个 5MB 开始并从那里测量）。如果您遵循，您会发现无需调整大小或重用内存；只需每隔几分钟为下一个N对象创建一个分配——不需要高频/高速对象分配和重新创建。
关于池分配器的事情会建议您需要很多具有不连续分配的对象，大量的插入和删除，如大分配列表 - 由于几个原因，这很糟糕。如果您想创建一个针对这种大小的连续分配进行优化的实现，只需针对具有向量方法的块。分配和查找都将接近最低限度。那时，分配时间应该很小（相对于您所做的其他工作）。然后，您的分配模式也不会有任何异常或令人惊讶的地方。但是，快速池分配器建议您将此集合视为列表，这对于此问题的性能很差。
一旦你实现了块+向量方法，更好的性能比较（那时）将是比较 boost 的 pool_allocator 和 std::allocator。当然，您可以测试所有这三个，但是如果您正确实现它，那么通过向量块方法可能会大大减少内存碎片。参考：
如果你非常关心性能，在处理 std::list 等容器时使用 fast_pool_allocator，在处理 std::vector 等容器时使用 pool_allocator。
于 2013-08-02T06:00:59.653 回答