提升图形库开销答案

【问题标题】：Boost Graph Library overhead提升图形库开销
【发布时间】：2021-09-07 10:18:39
【问题描述】：

在 ~21K 变量 (iNumVars ~21K) 的 for 循环中，我有以下代码 sn-p 其中 iNumVars 和 vars 都是整数，并且 vars 在大多数情况下为零（被忽略）并且在其他（有额外处理的）：

for (i=1; i<=iNumVars; i++) {
    if (vars[i]) {
    ... additional processing ...

在大约 21K 变量中，有 10 - 150 个是感兴趣的。在完成这项任务的另一种方式中，我可以使用 Boost Graph Library 并将 ~21K 变量标识为图中的顶点（变量名称 G）。过滤图 G 以识别 10 - 150 个感兴趣的变量，然后可以使用以下方法对其进行迭代：

auto vpair = vertices(filteredG);
for (auto iter=vpair.first; iter!=vpair.second; iter++) {
    ... the same additional processing as above ...

for 循环被调用了 1000 万次。我发现迭代数量少得多的顶点比迭代所有变量并仅进行布尔比较花费更长的时间。我不是快速 C++ 编码方面的专家，但这有意义吗？ Boost Graph Library 迭代器真的会减慢 for 循环吗？

需要注意的是，我没有展示图表 G 如何到达过滤后的版本 filtersG。但是，在任何情况下，出于其他原因，在上述行中的任何一个 for 循环中都会这样做，因此必须执行 10M 次 filter_graph 操作没有额外的时间损失。

谢谢，吉姆

【问题讨论】：

"for 循环被调用了 1000 万次。"每次调用时，非零变量是否相同？
不熟悉 Boost Graph 库，但作为建议，如果需要，我会将这 150 个项目存储在一个单独的向量中，其中仅包含感兴趣的对象及其对应的索引vector<pair<object, index>>
然而值得注意的是Graphs 通常不用于过滤事物。它们通常用于查找对象之间的关系，例如Travelling salesman problem
@Ranoiaetep 他们没有使用图表来过滤事物：他们正在过滤图表。
@sehe 他说以另一种方式来完成这项任务，我可以使用 Boost Graph Library...，这听起来像是他将数据放在向量/简单中之前的容器，但现在他将数据放入图表中只是因为 boost 有一个 filtered_graph 适配器。如果是这样的话，那么我认为使用图不是一个好方法，因为图是比简单向量重得多的结构。

【解决方案1】：

我发现迭代数量少得多的顶点比迭代所有变量并仅进行布尔比较花费更长的时间。我不是快速 c++ 编码方面的专家，但这有意义吗

是的。 Filtered Graph 是一个惰性适配器。这样做的好处是您可以拥有一个动态过滤器（逐步过滤掉更多例如）。缺点是谓词总是在运行中重新评估。

想法

我会考虑将过滤后的子集复制到单独的图表中，以便预先进行一次过滤。

你也可以

这些解决方案都不是真正简单的，所以也许您可以简化使用您的域逻辑？显然你有一个“神谕”可以告诉你哪些顶点是“感兴趣的”。为什么不将它们放在一个集合中并迭代集合本身而不是整个（过滤的）图？

【讨论】：

感谢您的所有意见。 10M 次迭代中的每一次在图上都有一个不同的过滤器，从而产生一组不同的 10 - 150 个顶点。我将查看子图并尝试制作一个单独的向量，尽管制作一个单独的向量似乎需要尽可能多的时间，因为 Filtered Graph 是一个惰性适配器。
子图只有在子集是“静态”或预先确定的情况下才有意义。并且可能不重叠。过滤可能仍然是要走的路，但您可能想要编写自己的过滤适配器（使用更智能的边缘/顶点迭代）。这可能看起来令人生畏，但就像我经常做的那样，如果我能看到完整工作的待优化代码，我会考虑和你一起看看。