c – 为什么我们需要使用folly :: fbvector而不是std :: vector with allocator最初保留大的uncommited区域？

概述众所周知,如果我们将push_back元素添加到std :: vector<>,并且如果向量中分配的整个内存被占用,那么std :: vector<>保留当前内存大小的2倍(分配2X大小的新内存),调整向量大小并将旧数据复制到新内存. 我们可以优化它,Facebook在愚蠢的库中完成这个(FBVector是Facebook的std :: vector的实现.它具有与可重定位类型和jemalloc 众所周知,如果我们将push_back元素添加到std :: vector<>,并且如果向量中分配的整个内存被占用,那么std :: vector<>保留当前内存大小的2倍(分配2X大小的新内存),调整向量大小并将旧数据复制到新内存.

我们可以优化它,Facebook在愚蠢的库中完成这个(FBVector是Facebook的std :: vector的实现.它具有与可重定位类型和jemalloc https://github.com/facebook/folly/blob/master/folly/FBVector.h#L21一起使用的特殊优化).

即当vector<>没有足够的内存来推送新的元素,然后我们分配更多的内存,但不是2倍以上(在不同的次数：1.3 – 1.5倍)

说明：https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md

The graphical solver below reveals that choosing k = 1.5 (blue line)
allows memory reuse after 4 reallocations,choosing k = 1.45 (red
line) allows memory reuse after 3 reallocations,and choosing k = 1.3
(black line) allows reuse after only 2 reallocations.

但为什么我们需要使用愚蠢的:: fbvector<>而不是std :: vector<>使用我们的自定义分配器,使用VirtualAllocEx()(如此处所示：For what do I need to use VirtualAlloc/VirtualAllocEx?),或者在linux https://stackoverflow.com/a/2782910/1558037中使用相同的,其中：

> std :: vector<> :: reserve() – 最初保留虚拟地址的大型未提交区域(分配WMA,但不在PT中分配任何PTE),例如最初分配16 GB的虚拟区域,每个时间缺少内存提交内存(分配PTE – 分配物理区域)等于1 x SIZE的向量
> std :: vector<> :: resize() – 然后只提交一批新的页面,在PT中只分配新的PTE,而不重新分配已使用的内存,也不将数据从旧内存复制到新内存

总体：

这种方法的优点是大的未提交区域超过了愚蠢的::向量<>：我们总是只分配新的内存部分而不会复制旧数据.

folly :: vector<>的优点接近std :: vector<>：有时我们不需要分配新内存,但应始终将旧数据复制到新内存中.

解决方法 这是特定于实现的. GCC库确实分配了两倍,但Visual C没有.我相信,它也使用1.5,但不确定.

我相信,愚蠢应该是与 *** 作系统无关的,你的方法是windows / linux特有的.

如果您仔细选择类型,那么从旧向量移动到新向量的对象应该不那么糟糕 – 也就是说,使用std :: unique_ptr作为数据类型.

总结

以上是内存溢出为你收集整理的c – 为什么我们需要使用folly :: fbvector而不是std :: vector with allocator最初保留大的uncommited区域？全部内容，希望文章能够帮你解决c – 为什么我们需要使用folly :: fbvector而不是std :: vector with allocator最初保留大的uncommited区域？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。