c++ - 我应该认为静态拷贝很昂贵吗？

Question

当我遍历一个集合时，说一个 Point 的 vector Point在哪里是一些包含 x 的结构, y , z数据或其他东西，当我需要一次将这些点转换为另一种类型时，我是否应该将其视为与拷贝一样昂贵？

例如，如果我有一个 vector<Point> v ，我显然尽量避免:

vector<OtherPointType> vo;
// populate v
std::transform(v.begin(), v.end(), vo.begin(),
   [](Point const& p) { return OtherPointType{p.x, p.y, p.z}; });
SomeOperation(vo); // Can only operate on vector<OtherPointType>

但是，这样做的成本是不是很高:

for_each(..., [](Point const& p)
{
   OtherPointType opt(p.x, p.y, p.z);
   SomeOperation(opt); // Can only operator on `OtherPointType`
});

?

我的直觉告诉我，因为后者是没有任何动态分配的静态拷贝，所以它应该不会很昂贵，但我认为它很重要，所以要问。

通常我可以使用类似 Eigen::Map 的东西在后一种情况下，但即使在那里我仍然写信给两个 int s(在堆栈上)我认为是由于 Eigen::Stride (在这种情况下，这甚至是一个好的解决方案吗？)但是像 CGAL 这样的库没有映射功能，我很好奇使用它们的好方法。

请注意，我的工作通常每秒处理一百万个点，因此我尽量减少昂贵的拷贝很重要。

更新

关于我想知道是否 Eigen::Map 的子问题在上面的后一种情况下会很好:

我运行了一个 benchmark ，并且至少使用 gcc 5.4，即使有 1 亿点，结果也太接近了。使用 Eigen::Map vs 构建 Eigen::Vector3d分别花费了 276 毫秒和 285 毫秒。尽管构建花费的时间更少，但点数更少，这告诉我这里的区别在于不确定性和我计算机上运行的其他进程可能产生了更大的影响。

Answer 1

should I consider [conversion] as costly as a copy?

因为是不同的操作，不一定。它的成本可能或多或少。然而，将其与拷贝相媲美是合理的。

But, is [copying a vector] as expensive as [iterating a vector and copying each element onto an automatic variable]

可能不会。

My instinct says that because the later is a static copy without any allocations, that it shouldn't be expensive

这就是为什么后者可能没有前者贵的原因。但后者是否昂贵取决于具体情况。它仍然是一个具有线性渐近复杂度的操作，因此如果 vector 很大，与拷贝相比分配可能是微不足道的。

在您的硬件上是否有什么东西比其他东西更昂贵，以及在您的程序上下文中是否有什么东西是昂贵的，您可以尝试使用分析器找出答案。