分配器在新运算符中的平均时间答案

【问题标题】：average time for allocator in new operator分配器在新运算符中的平均时间
【发布时间】：2013-09-16 14:33:33
【问题描述】：

我在分配一些内存时总是读新的很慢，但从来没有发现它有多慢。所以我开始了一些研究和测试。

假设，我有一个缓冲区，它是一个向量（例如用于以太网接收器）。

我可以使这个缓冲区成为一个类的成员，用数据填充它，然后将此缓冲区复制到用户定义的缓冲区。
我可以创建一个新缓冲区并将其移动到用户定义中。

所以现在我的问题是哪个更快。在网上搜索时，我并没有真正找到任何基准或其他东西。所以我开始了一些测试。

这 2 个变量不是接收器！

复制变体

auto time = GetTickCount();
std::vector<int> vec;
std::vector<int> tmp(250);

for(int i=0; i<10000; i++) {
  for(int i=0; i<1000; i++) {
    vec.insert(vec.end(), tmp.begin(), tmp.end());
    //std::copy(tmp.begin(), tmp.end(), std::back_inserter(vec1));
  }
  vec.clear();
}

std::cout << GetTickCount() - time << std::endl;

移动变体

auto time = GetTickCount();
std::vector<std::vector<int> > vec;

for(int i=0; i<10000; i++) {
  for(int i=0; i<1000; i++) {
    std::vector<int> tmp(250);
    vec.push_back(std::move(tmp));
  }
  vec.clear();
}

std::cout << GetTickCount() - time << std::endl;

我知道分配内存取决于硬件、操作系统和内存管理，但是我可以说创建一个新的并移动它比复制现有的更好吗？在我的测试中，我发现处理具有 250 个元素的向量需要与移动大约相同的时间，而超过 250 个元素的复制变体比移动的慢。确定在我的测试中，移动变量是向量的向量并且迭代更加困难，但这在我的（大多数）情况下并不重要。测试也是用 int 的，而不是一些会使问题复杂化的结构或类。

我的测试也是在 Windows 机器上进行的（又快又脏）。我的兴趣是普通硬件和普通系统（windows、linux、mac）的平均时间（或在我的条件下、大小）。

我可以参加测试并说复制超过 400 个元素比创建一个新元素要慢吗？

编辑：

Neil Kirk 建议我尝试随机分配大小，所以我做到了。我还插入了一些其他的东西，在测试和平均大小增加到大约 1000 个元素之间进行分配（但没有删除）。

我接受 Mats Petersson 的回答，尤其是在阅读 this（和子链接）和 this（除了它是唯一的）之后。但我有 1 个补充：您无法知道它是否是 过早优化 没有任何估值。如果一个 alloc 需要与复制 100000 个元素相同的时间，我永远不会使用它，否则如果它需要与复制 10 个元素相同的时间，我会一直使用它。但是在我将网络作为瓶颈的网络场景中，大约有 1000 个元素，我可以说这是过早的优化。所以我决定使用 ne 分配变体，因为它在我的概念中更有用。

【问题讨论】：

@R.MartinhoFernandes 我认为 c++11 会暗示 c++ :)
是的，但网站不知道 :)（即它会影响过滤器和搜索）
学习永远不会太晚... thx
尝试分配随机大小，使系统更难找到空闲块。还可以在测试运行一段时间后尝试对时间进行采样，以检测内存碎片。
还请记住，这将高度依赖于您正在使用的标准库的实现。 C++ 没有定义必须用于其实现的内存模型，因此每个实现都使用稍微不同的模型。有些人在某些任务上比其他人更有效率。

标签： c++ performance c++11 copy move

【解决方案1】：

这是“过早优化”的典型案例。找出你的这部分代码是否是影响性能的重要因素。如果不是，那么不要担心——做任何对手头的实际任务最有意义的事情。

一般来说，分配内存是相当快的——对于除基本类型（int、char 等）以外的任何东西，主要因素可能是创建/复制/移动进入的对象所需的时间向量，而不是基本分配。

【讨论】：