Boost Graph Library 开销

如何解决Boost Graph Library 开销

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

var utf8NoBOM = new UTF8Encoding(false);

var bidsXml = string.Empty;

var emptyNamespaces = new XmlSerializerNamespaces(new[] { XmlQualifiedname.Empty });

var settings = new XmlWriterSettings();
settings.Indent = true;
settings.OmitXmlDeclaration = true;

activity = $"Serialize Class INFO to XML to string";
using (MemoryStream stream = new MemoryStream())
using (StreamWriter writer = new StreamWriter(stream,utf8NoBOM))
{
  XmlSerializer xml = new XmlSerializer(info.GetType());

  xml.Serialize(writer,info,emptyNamespaces);

  bidsXml = utf8NoBOM.GetString(stream.ToArray());
}


var fileName = $"CostOffer_Testing_{DateTime.Now:yyyy.MM.dd_HH.mm.ss}.xml";

var path = $"c:\\temp\\pjm\\{fileName}";
File.WriteallText(path,bidsXml,utf8NoBOM);

在 ~21K 变量中，有 10 - 150 个感兴趣。以另一种方式完成此任务，我可以使用 Boost Graph Library 并将 ~21K 变量标识为图中的顶点（变量名称 G）。图 G 被过滤以识别 10 - 150 个感兴趣的变量，然后可以使用：

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

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

一个注意事项是我没有展示图形 G 是如何变成过滤版本filteredG的。然而，这在任何情况下都是出于其他原因在上述任一 for 循环行中完成的，因此不必执行 10M 次 filter_graph 操作没有额外的时间损失。

谢谢， 吉姆

解决方法

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

是的。过滤图是一个懒惰的适配器。这样做的好处是您可以使用动态过滤器（例如逐步过滤掉更多）。缺点是谓词一直在不断地重新评估。

想法

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

你也可以

• 意识到 vecS 使顶点描述符成为向量的序数索引，这在某种程度上消除了优化子集的任何希望操作（因为仍然需要枚举源图的整个域）
• 查看子图。它们具有相似的语义（子图继承父图中的所有节点），但您仍然可以单独对父图进行操作。这会产生不同的折衷，因为描述符需要在图的层之间进行转换/投影。

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