这是这个 MIC question的后续问题。在将项目添加到引用包装器的向量时，无论我选择哪种迭代方法，我都会在 ++ 运算符中花费大约 80% 的时间。
查询工作如下
VersionView getVersionData(int subdeliveryGroupId, int retargetingId,
const std::wstring &flightName) const {
VersionView versions;
for (auto i = 0; i < 3; ++i) {
for (auto j = 0; j < 3; ++j) {
versions.insert(m_data.get<mvKey>().equal_range(boost::make_tuple(subdeliveryGroupId + i, retargetingId + j,
flightName)));
}
}
return versions;
}
我尝试了以下方法来填充参考包装
template <typename InputRange> void insert(const InputRange &rng) {
// 1) base::insert(end(), rng.first, rng.second); // 12ms
// 2) std::copy(rng.first, rng.second, std::back_inserter(*this)); // 6ms
/* 3) size_t start = size(); // 12ms
auto tmp = std::reference_wrapper<const
VersionData>(VersionData(0,0,L""));
resize(start + boost::size(rng), tmp);
auto beg = rng.first;
for (;beg != rng.second; ++beg, ++start)
{
this->operator[](start) = std::reference_wrapper<const VersionData>(*beg);
}
*/
std::copy(rng.first, rng.second, std::back_inserter(*this));
}
无论我做什么，我都会为运算符 ++ 或只是增加迭代器的 size 方法付费——这意味着我仍然停留在 ++ 中。所以问题是是否有一种方法可以更快地迭代结果范围。如果没有这样的方法，是否值得尝试执行 equal_range 添加新参数，该参数保存对 reference_wrapper 容器的引用，该容器将填充结果而不是创建范围？
编辑 1：示例代码
http://coliru.stacked-crooked.com/a/8b82857d302e4a06/
由于这个错误，它不会在 Coliru 上编译
编辑 2：调用树，时间花在运算符 ++
编辑3：一些具体的东西。首先，我没有启动这个线程只是因为 operator++ 在整体执行时间上花费了太多时间，而且我不喜欢它只是“因为”但此时它是我们性能测试的主要瓶颈。每个请求通常在数百微秒内处理，与此类似的请求（它们稍微复杂一些）处理约 1000-1500 微秒，仍然可以接受。最初的问题是，一旦数据结构中的项目数量增长到数十万，性能就会下降到大约 20 毫秒。现在，在切换到 MIC（这极大地提高了代码的可读性、可维护性和整体优雅性）之后，我可以达到每个请求大约 13 毫秒的时间，其中 80%-90% 花费在 operator++ 上。现在的问题是这是否可以以某种方式改进，还是我应该为我寻找一些焦油和羽毛？:)
