【发布时间】:2014-11-16 21:39:07
【问题描述】:
我预计要处理大量数据记录,其中大约 20 个 uint8_t 键将有数百万个 <int, struct> 对与它们相关联(按 int 排序)。这些对相当轻巧,大约 10 个字节,需要动态分配。
最初,我使用的是std::map<uint8_t, std::vector<int, struct>>,但在研究了与向量相关的开销后,即
capacity()
总共3个机器字+
sizeof(element)*capacity()
如看到here; capacity()“通常可以容纳两倍于实际数量的元素”,这似乎是有害的。
我可以使用 std::map 来代替向量,但是 ~32 bytes per node 的开销对于此类轻量级对也变得非常昂贵。
我不熟悉 Boost 和其他 C++ 库,所以想知道是否有人可以建议我可以避免手动动态内存分配的解决方案?
编辑:为了澄清以下 cmets 中的几个问题,存储的结构将包含 3 个短裤(开始),并且没有其他数据结构。我预计vector 的长度不超过 1.5*10^8,并且理解为 ~1.4 GiB(感谢@dyp)。
我想问题是,如何管理向量capacity(),以便将通过reserve() 的重新分配保持在最低限度。我也不确定shrink_to_fit()(C++11)的效率
【问题讨论】:
-
结构中有什么?矢量的典型大小是多少?它有最大值吗?在编译时是否已知?
-
@πάνταῥεῖ 这不只是至少这个数量的元素的建议吗?
-
您可以推出一个“平面图”,即
std::vector<std::pair<key, value>>,并通过在操作前对向量进行排序,您可以使用std::lower_bound和类似的函数来执行二分查找。在 boost 中可能有一个预制的这样的结构。 -
数百万对 10 字节对我来说听起来像是几十兆字节。其中 20 个仍然可以是数百兆字节到几千兆字节的数量级。这真的是目标机器的问题吗?
-
您引用的答案是正确的,但可能会误导您。他基本上是在说容量可能是当前大小的两倍。这只有在增长因子至少为 2 时才会发生,即使这样也只会在重新分配后立即发生。更典型的情况是增长因子为 1.5,增加的面积约为半满,因此浪费的面积约为 25%。我从未见过大于 2 的增长因子。等于 2 曾经很常见,但 1.5 在当前实现中似乎很常见。