代码如下:
#include <iostream>
#include <vector>
#include <chrono>
using namespace std;
using namespace chrono;
const int maxn = int(5e7);
vector<int> G[maxn];
vector<int> a;
int main()
{
/*
for(int i = 0; i < maxn; ++i)
a.push_back(rand());
*/
for(int i = 0; i < maxn; ++i)
G[i].push_back(rand());
return 0;
}
在 release 编译运行下前者需要 2.8s 后者则需要 7.8s
 |
1
shylockhg Apr 22, 2019
寻址缓存
|
 |
5
0x11901 Apr 22, 2019
是不是因为第一个 vector 事先指定了大小。而另一个先随便蒙了个大小，发现空间不够了就把大小变成 1.5 倍。然后翻倍时发现内存连续空间不足以放下翻倍后的 vector 了之后，又到其他地方 alloc 一段空间，再把原来的数据复制过去，再释放原来位置的内存。反复多次就这样了。
|
 |
6
SAIKAII Apr 22, 2019 via Android
第二个每次 push_back()都分配新的内存吧，第一个是会分配大的内存，不够再重新分配。
|
 |
7
pwrliang Apr 22, 2019 via Android
第一个连续内存访问有加成吧…虽然要扩容
|
 |
8
GeruzoniAnsasu Apr 22, 2019
拿 clion 的 profiler 跑一下就能很直观地看到差异了
我这边的结果是， 第二种方式 97%的时间花在了一个叫__push_back_slow_path 的过程，这个过程包含了构造，这其中又有 79%的时间完全是在调用 operator new 与之相比，第一种方式仅有非常少量的__push_back_slow_path，推测是扩容时真正的 push_back，而其余所有的 push 都被优化成了 emplace new，只能看到 rand 函数的调用 |
|
9
GeruzoniAnsasu Apr 22, 2019
补充一句 STL 的经验谈：
如果你发现某个 STL 容器效率很低，一定是频繁申请释放空间导致的，不要用 STL 的队列或者链表作为高速缓存，除非在使用 c++17 的 pmr allocator 并且你会写基于内存池的 allocator |
 |
10
ipwx Apr 22, 2019
因为很多 vector 的实现是，如果 push_back 内存不够，那么就申请 2 倍与现在大小的内存，把现在的元素拷贝进去，然后释放原内存。此外，空的 vector 不申请内存，直到第一个元素放进去，才会申请一块有最小大小的内存。最小大小一般不会是 1。
你的第一种方式，在这个逻辑下，总共申请了 log2(maxn) 次内存。但是第二种方式申请了 maxn 次内存。 申请内存的时间开销不用我说吧？ |
|
11
ipwx Apr 22, 2019
顺便地，我上面的分析和 @GeruzoniAnsasu 老哥的实验结果一致。不过话说，我认为这种问题不需要上 profiler，看过 STL 代码或者思考过如何自己实现 vector 的应该都清楚。。。
|
 |
12
kljsandjb Apr 22, 2019 via iPhone
直观感觉第二个空间局部性不友好吧…
|
 |
14
RicardoY OP |
Select Language