提升 multi_index_container 和慢操作员++

Posted 2023-02-22

【中文标题】提升 multi_index_container 和慢操作员++

【英文标题】：boost multi_index_container and slow operator++

【发布时间】：2014-12-21 09:03:14

【问题描述】：

这是this 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/ 由于this bug，它不会在 Coliru 上编译 编辑 2：调用树，时间花在运算符 ++ 编辑3：一些具体的东西。首先，我没有启动这个线程只是因为 operator++ 在整体执行时间上花费了太多时间，而且我不喜欢它只是“因为”但此时它是我们性能测试的主要瓶颈。每个请求通常在数百微秒内处理，与此类似的请求（它们稍微复杂一些）处理约 1000-1500 微秒，仍然可以接受。最初的问题是，一旦数据结构中的项目数量增长到数十万，性能就会下降到大约 20 毫秒。现在，在切换到 MIC（这极大地提高了代码的可读性、可维护性和整体优雅性）之后，我可以达到每个请求大约 13 毫秒的时间，其中 80%-90% 花费在 operator++ 上。现在的问题是这是否可以以某种方式改进，还是我应该为我寻找一些焦油和羽毛？ :)

【问题讨论】：

"如果没有这样的方法，是否值得尝试执行 equal_range 添加新参数，该参数包含对 reference_wrapper 容器的引用，该容器将填充结果而不是创建范围？ " - 你在说什么？当然，如果您复制实现，则不会有任何区别。此外，“创建范围”并不是一项昂贵的操作。你有没有描述过operator++ 中的什么 花费了这么多时间？您可能只是在查看遍历基于节点的数据结构的成本。

我要再说一遍：如果您需要认真的帮助，请至少发布所涉及的数据结构声明。使示例独立，并包含一些表现出您所说的不良性能的数据。

你是完全正确的。我必须完全禁用内联才能在探查器中查看确切的行。它是 multi_index/detail/ord_index_node.hpp 中“增量”方法的实现——“while(x->left()!=pointer(0))x=x->left();”花费 40% 的时间。

将尝试编写自包含测试

MIC 在调试模式下验证迭代器。确保在发布模式下编译（有优化，没有 MIC debugging macros）。

【参考方案1】：

getVersionData 80% 的执行时间花在operator++ 上这一事实本身并不表明存在任何性能问题——最多，它告诉您equal_range 和std::reference_wrapper 插入速度更快相比下。换句话说，当您分析一段代码时，您通常会找到花费最多时间的位置，但这是否是一个问题取决于所需的整体性能。

【讨论】：

用示例、代码和分析结果更新问题

我不会因为 op++ 需要很多时间而提出问题，这是目前的瓶颈。稍后将提供具体时间

【参考方案2】：

@kreuzerkrieg，您的示例代码不会对vector 的std::reference_wrappers 进行任何形式的插入！相反，您将equal_range 的结果投影到boost::any_range，预计在迭代时会相当慢——基本上，增量操作解析为虚拟调用。

所以，除非我在这里严重遗漏了什么，否则示例代码的性能或缺乏与您在实际代码中的问题没有任何关系（假设 VersionView，其中您没有显示代码, 没有使用boost::any_range)。

也就是说，如果您能够负担得起用等效的散列索引替换您的有序索引，迭代可能会更快，但鉴于您没有显示真实的东西，这完全是在黑暗中拍摄。

【讨论】：

现在我不插入参考包装器，如果我这样做只是将问题从一个地方转移到另一个地方 - getData（我排除了测量，因为得到 equal_range 可以忽略不计）将花费所有时间将花费在迭代结果并插入向量中。我也会发布这个案例。

这里是 coliru.stacked-crooked.com/a/7d44672d44e49602 插入向量时大部分时间花在 std::distance 和 operator++ 上

顺便说一句，我也检查过散列索引，它们比有序索引快两倍

【参考方案3】：

我认为你衡量的东西完全是错误的。当我从 3x3x11111 放大到 10x10x111111（索引中的项目数是 111 倍）时，它仍然在 290 毫秒内运行。

填充这些东西需要更多时间。即使解除分配容器似乎也需要更多时间。

什么不重要？

我提供了一个有一些取舍的版本，主要表明调整东西没有意义：View On Coliru

有一个开关可以避免使用any_range（如果您关心性能，那么使用它没有意义）

有一个开关可以调整享元：

#define USE_FLYWEIGHT 0 // 0: none 1: full 2: no tracking 3: no tracking no locking

再次，它只是表明您可以轻松地做到这一点，并且应该考虑这样做，除非您需要对字符串 (?) 进行内存优化。如果是这样，请考虑使用OPTIMIZE_ATOMS 方法：

OPTIMIZE_ATOMS 基本上可以为wstring 提供重量。由于所有的字符串都在这里重复，这将是非常有效的存储效率（尽管实现又快又脏，应该改进）。这个想法在这里应用得更好：How to improve performance of boost interval_map lookups

这里有一些基本的时间安排：

如您所见，对于查询/迭代性能而言，基本上没有什么真正重要

任何迭代器：它们重要吗？

这可能是编译器的罪魁祸首。在我的编译 (gcc 4.8.2) 中，这没什么大不了的，但是请查看累积循环的反汇编没有任何迭代器：

正如您从我强调的部分中看到的那样，算法、lambda 和迭代器遍历似乎并不多。现在使用 any_iterator 情况就不太清楚了，如果你的编译优化不太好，我可以想象它无法内联基本操作，从而导致迭代变慢。 （现在只是猜测）

【讨论】：

令人印象深刻！我真的很感谢你的努力。不幸的是，我测量了正确的东西，因为数据的负载（和破坏）并不重要。在现实生活中，数据从 DB 加载并存储在 LRU 缓存中，该缓存足够大，实体不会被弹出，因此它很高兴地驻留在那里，直到实体无效（更新 DB，罕见的东西）或 TTL 过期（20分钟），因此加载时间问题远没有那么严重。无论如何，几乎免费拥有更好的加载时间是件好事。

刚刚运行了 any_range 与 iterator_range，像你一样使用 1111100 个项目，我得到了 50 和 49 微秒的 std::accumulate。这是一个非常烦人的结果，因为根据“性能”部分，any_range 必须比其他任何东西都慢......这是我的编译器的错吗？将尝试找到带有 GCC 的 linux 机器并在那里进行测试

正如您在时序表中看到的，与 GCC 中的 any_range 也没有太大区别。这就是重点：我只是没有看到瓶颈（嗯，超出了预期的范围）。如果 MSVC 没有搞砸，那么我想没关系，除非您可以查明生成的程序集中的问题。 GASP： 50 微秒？这是令人印象深刻的快。我得到了约 280 毫秒，而不是微秒。然后我确实使用了 11,111,100（不是你在评论中提到的 1,111,100）。您是否注意到我“修复”了 res 和初始化程序 (0ll) 的容量以避免整数溢出时出现未定义行为？

呵呵呵呵。我敢打赌这是（a）未显示（b）与编译标志相关的东西：/现在我很好奇

不，这些都不是，解决方案是可怕的 MIC 滥用。实际上我不明白，为什么你看不到问题？或者问题不够严重，或者由于内联，您无法在分析器中定位问题？它只是显示在其他地方花费的时间？实际上这就是为什么我的测试中有两个 cin.get() 的原因，我正在启动分析器暂停并在填充数据后恢复分析

【参考方案4】：

好的，所以我应用的解决方案如下： 除了 odered_non_unique 索引（'byKey'），我还添加了 random_access 索引。加载数据后，我使用 m_data.get.begin() 重新排列随机索引。然后，当向 MIC 查询数据时，我只需使用自定义谓词对随机索引执行 boost::equal_range，该谓词模拟在“byKey”索引排序中应用的相同逻辑。就是这样，它给了我快速的'size()'（O(1)，据我所知）和快速遍历。 现在我准备好了你的烂番茄:)

编辑 1： 当然，我已经将 any_range 从双向遍历标签更改为随机访问标签