可能重复:
std::vector 向下调整大小
如果我resize()
的std::vector
大小比其当前大小小一些,向量是否有可能分配新内存?
出于性能原因,这对我很重要。
不,resize
ing 到更小的大小将永远不会重新分配。
如果容器缩小,所有迭代器、指针和对未删除元素的引用在调整大小后仍然有效,并引用它们在调用之前引用的相同元素。
(从这里)
鉴于此,我们可以确定不会发生重新分配。
resize()
减少时仅更改逻辑大小。其他人已经回答了这个问题,所以我在这里不添加任何内容。这样做的目的是优化速度,因为它不需要重新分配或移动任何数据。
但是,当您想要优化内存使用时,C++11 引入了一个进一步的函数shrink_to_fit()
,您可以在您之后resize()
(甚至在任何其他时间)调用它,这实际上将确保您无需为任何您不想要的内存付费.
不会。除非在一些非常特殊的情况下,vector
否则永远不会缩小它的内存。请记住,当vector
调整大小时,迭代器会失效,所以它不能在你背后做这件事——这是一个可观察的变化,标准准确地指定了这可能会或可能不会发生的时间。
不。
Vector 使用两个值:size和capacity。大小是存储在向量中的实际元素数量,而容量是指在内存中分配的保留空间。性能提升来自于分配比需要更多的空间。
仅当执行将导致容量大于当前容量的调整大小请求时,才会进行重新分配。此外,如果您尝试在向量中间插入大量元素,则会影响算法性能,因为插入元素之后的所有元素都需要移动(有时,如果超出容量,这可能会触发重新分配向量)。
您可以使用保留成员函数进一步提高速度:保留成员函数将确保将容量设置为特定值。
您可以在第 148 页阅读有关 std::vector 的更多信息 - 在C++ 标准库:教程和参考一书中。
首先你必须衡量你想要优化的东西,仅仅性能是不够的,你是什么意思?用户界面反应性?这需要您测量时间的典型用户操作。重算法?等等...然后你必须找到瓶颈在哪里,可能是内存、磁盘访问等,最后可能是vector::resize,但只在最后!而你问问题的方式,我敢打赌我的 $ that vector::resize 不会成为瓶颈。
对 STL 的设计方式充满信心,在修改 STL 行为之前检查您的代码;-)