STL矢量内存占用 [英] STL vector memory footprint
问题描述
如果已在某处回答道歉，但谷歌没有产生任何具体的结果。
结果。我想找出一个向量< T>的内存占用。
我试图挖掘STL代码，如果我理解正确，它的3 *
void（*）+
sizeof（T）* size_of_vector。 （3 ptrs为__M_start，__ M_finish和
__M_end_of_storage）。
如果任何STL大师可以确认我的发现，那将是非常值得赞赏的。
另外，如果有人可以输入STL hashmap的内存编号并设置
，那就太棒了！
谢谢。
Varun Kacholia< ka ****** @ gmail.com>写道：道歉，如果已在某处得到解答，但谷歌没有产生任何具体的结果。我想找出一个向量< T>的内存占用。
我试图挖掘STL代码，如果我理解正确，它的3 *
void（*）+
sizeof（T）* size_of_vector。 （3 ptrs for __M_start，__ M_finish和
__M_end_of_storage）。
如果任何STL大师可以确认我的发现，那将非常感激。
此外，如果有人可以投入STL hashmap的内存编号和
设置，
非常棒！
您挖出的内容特定于您的实现。我的可能是完全不同的
。使用sizeof有什么问题（std :: vector< T>）
（其中T是你要存储的类型）？
hth
-
jb
（rot13中的回复地址，先解读）
Varun Kacholia写道：我想找出一个向量< T>的内存占用。
我试图挖掘STL代码，如果我理解正确，它的3 *
void（*）+ sizeof（T）* size_of_vector。
基本上，''3 sizeof（T *）+ v.capacity（ ）* sizeof（T）''基本上是最低存储要求的b $ b。可能还有一个额外的单词
分配器可以针对标准分配器进行优化
但是可能需要额外的内存用于其他分配器。
''std :: set< T>''或''std :: tr1 :: unordered_set< T>'
的内存占用量将大于每个对象，可能也是每个容器。对于
''std :: set< T>''计算可能类似于
''3 * sizeof（Node *）+ s.size（）* （sizeof（T）+ 3 * sizeof（节点*）+
sizeof（void *））''。这实际上是一个指向树根的指针，
最左边的容器和最右边的树节点。对于每个
对象，节点存储对象加上左右指针
子树以及相对平衡的一些表示，例如颜色
红色和黑色或一些整数值。这有效地结束了由于填充而导致指针大小的
。一个额外的指针会指向节点的父节点，但是这不是真正的
，以满足标准的性能要求，但是
阻碍迭代。根据分配器的不同，每个
对象可能需要一个额外的单词来包含内存块的大小但
这可以相对容易地避免并且可以像
'block / sizeof（Node）''元素的一个单词。
对于''std :: tr1 :: unordered_set< T>''事情变得更加不清楚：
哈希策略可能会有很大不同，并且在对象分配和冲突方面有各种各样的b / b
权衡。这将
影响容器大小和每个对象大小。我想
一般来说，开销比'std :: set< T>''的开销稍微小一些，但远远大于'std :: set< T>''的开销
''std :: vector< T>''。
你的实际问题是什么，BTW？
-
< mailto：di *********** @ yahoo.com> < http://www.dietmar-kuehl.de/>
< http://www.eai-systems.com> - 高效的人工智能
>什么是你的实际问题，BTW？
尝试通过比较不同容器的消耗来优化内存使用量。
jb：sizeof（vector< T>）不会工作，因为STL容器会分配一些内存
在堆上也是b $ b。
Apologies if this has been answered somewhere, but Google did not
produce any concrete
results. I would like to find out the memory footprint of a vector<T>.
I tried to dig in the STL code and if I understand correctly, its 3 *
void(*) +
sizeof(T) * size_of_vector. (3 ptrs for __M_start, __M_finish and
__M_end_of_storage).
If any STL guru could confirm my findings, that would be much
appreciated.
Also, if someone could throw in the memory numbers for STL hashmap and
set,
that would be great!
Thanks.
Varun Kacholia <ka******@gmail.com> wrote:Apologies if this has been answered somewhere, but Google did not
produce any concrete
results. I would like to find out the memory footprint of a vector<T>.
I tried to dig in the STL code and if I understand correctly, its 3 *
void(*) +
sizeof(T) * size_of_vector. (3 ptrs for __M_start, __M_finish and
__M_end_of_storage).
If any STL guru could confirm my findings, that would be much
appreciated.
Also, if someone could throw in the memory numbers for STL hashmap and
set,
that would be great!
What you dug up is specific to your implementation. Mine might be
completely different. What is wrong with using sizeof (std::vector <T>)
(where T is the type you are storing)?
hth
--
jb
(reply address in rot13, unscramble first)
Varun Kacholia wrote:I would like to find out the memory footprint of a vector<T>.
I tried to dig in the STL code and if I understand correctly, its 3 *
void(*) + sizeof(T) * size_of_vector.
Essentially, ''3 * sizeof(T*) + v.capacity() * sizeof(T)'' is essentially
the minimum storage requirement. There may be an additional word for
the allocator which can be optimized away for the standard allocator
but might require additional memory for other allocators.
The memory footprint for ''std::set<T>'' or ''std::tr1::unordered_set<T>''
will be bigger per object and probably also per container. For
''std::set<T>'' the computation is probably something like
''3 * sizeof(Node*) + s.size() * (sizeof(T) + 3 * sizeof(Node*) +
sizeof(void*))''. This is effectively a pointer to the tree root, the
left most and the right most tree nodes for the container. For each
object, a node stores the object plus pointers to the left and right
subtree and some representation of the relative balance e.g. colors
"red" and "black" or some integer value. This effectively ends up to
be the size of a pointer due to padding. An additional pointer would
point to the parent of the node although this is not really
necessary to meet the standard''s performance requirements but would
impede iteration. Depending on the allocator, an extra word per
object might be necessary to contain the size of the memory block but
this can be relatively easily avoided and be traded for something like
one word for ''block / sizeof(Node)'' elements.
For ''std::tr1::unordered_set<T>'' things become even more unclear: the
hashing strategies can be rather different and there are various
trade-offs with respect to object allocation and conflicts. This will
affect both the container size and the per object size. I would
expect that in general the overhead is a little bit smaller than that
of the ''std::set<T>'' but substantially bigger than that of
''std::vector<T>''.
What is your actual problem, BTW?
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
> What is your actual problem, BTW?
Trying to optimize the memory usage by comparing the consumption of
different containers.
jb: sizeof(vector<T>) wont work as STL containers allocate some memory
on
the heap too.
这篇关于STL矢量内存占用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
