Performance 容格图性能——稠密图上的PageRank

考虑到我使用的数据，我想知道JUNG2和PageRank相对较慢的性能是否合理

给定一个具有约200个顶点和约40000条边的图，计算图的PageRank大约需要15秒。给定一个具有约900个顶点和约800000条边的图，计算该图的PageRank大约需要5分钟

我意识到这些图非常密集，可能这自然需要一段时间来计算。然而，这些图不是特别大，以这种速度，一次只计算一个图的一小部分是不可能的。对于10000个顶点和100000000条边，大约需要8小时

我使用的是一个DirectedSparseGraph，它的顶点和边都是原始整数，没有边权重。这些显然不是稀疏图，所以也许有一种更合适的图结构可以用于稠密图

我在服务器模式下运行jvm，占用了大量的堆空间，并且已经确认整个图形适合内存，并且没有使用交换

排名结果正确，总和为1，与Jung source和其他地方的测试示例相匹配

也许有一种更高性能的方法和/或库可以实现这一点？但是，即使它快了10倍，它的时间复杂度似乎与边的数量成正比，这难道不意味着我很快就会超过我使用的任何方法的极限吗

例如，我考虑过完全跳过图形方法，使用矩阵来表示转移概率，这可能会带来显著的提升。但是，PageRank并不是我感兴趣的唯一算法。如果我开始使用自己的方法，可以解决一个问题，并引入其他几个问题

另外，我是在一个慢盒上，双核1Ghz，所以，你的数字可能会更好，比如说我的第一个例子中的4-5秒，但这一点是正确的。我主要关心的是，代码的运行速度是否会加快几个数量级，或者是否会按对数扩展

---

无论如何，谢谢你的见解。

tl；dr：这是PageRank算法固有的局限性，渐进地说

任何想要考虑所有边的算法都将具有时间复杂度，即ω| E |。任何试图测量全局拓扑特性的算法，比如特征向量测量，比如PageRank，都必须至少观察每条边一次

通过更改图形实现，您可能可以通过一些常量来提高性能，但最终在密集图形上进行操作往往会很昂贵

框架问题：你的图形的语义是什么？你希望从中学习什么

---

计算网页排名？你想解决什么问题？

我正在对文本正文中的句子进行排序，其中节点是句子，边缘是它们的语义相似性。你可以想象，在我进入页面排名之前，nlp处理已经很昂贵了。我可以通过消除不太可能在最终结果中考虑高因素的低评分边缘来显著减少边缘。另外，我使用一个有2Vn边的有向图来说明每个原点顶点的不同权重。这可以通过覆盖GetEdgeWights来改进，正如您在相关问题中所建议的那样。换句话说……我唯一的选择似乎是通过任何必要的方式减少边的数量，以便计算任何大型图形。但我想知道如何计算非常大的图形？把硬件放在这个问题上？我同意全对NLP可能比PR计算要贵一些。为了减少边缘，您可以尝试对句子进行聚类，如果您有某种方法可以做到这一点，但该方法不同时启用，然后计算簇内边缘。不确定计算这种网络的公关有什么意思，但这是你的问题关于大型图的计算，有两个基本答案：1大型完整图非常罕见，对于非常多的节点来说是不切实际的；2是的，对于大型图，在此类问题上投入资源是必要的。对于稀疏图，计算通常至少在某种程度上是可并行的，尽管管理图算法的并行性本身是一件棘手的事情。