我想知道我在JUNG2和PageRank中遇到的相对较慢的表现是否合理，考虑到我正在使用的数据。
给定一个包含~200个顶点和~40000个边的图，计算图的PageRank大约需要15秒。给定一个包含~900个顶点和~800000个边的图，计算图的PageRank需要将近5分钟。
我意识到这些图表非常密集，可能自然需要一段时间来计算。然而，这些图形并不是特别大，并且按照这个速度，除了一次图形的一小部分之外，不可能计算任何东西。 （10,000个顶点和100,000,000个边缘约8小时）。
我正在使用带有原始整数的DirectedSparseGraph作为顶点和边，而没有边权重。这些显然不是稀疏图，所以也许有一个更合适的图形结构可以用于密集图形更优化？
我在服务器模式下运行jvm，堆空间很大，并确认整个图形适合内存并且没有使用交换。
排名的结果是正确的，总和为1，并匹配Jung source和其他地方的测试示例。
也许有更高性能的方法和/或库？但是，即使速度提高了10倍，事实上它的时间复杂度似乎与边数成正比，这意味着我很快就会超越无论方法的极限我在用？
例如，我考虑过完全跳过图表方法并使用矩阵来表示转换概率，这可能会提供显着的提升。但是 - PageRank并不是我唯一感兴趣的算法。如果我开始推出自己的方法，可以解决一个问题并引入其他几个。
另外，我在一个慢速盒子，双核1Ghz，所以，你的数字可能会好很多（就像我的第一个例子说4-5秒），但重点是。我主要担心的是，如果预计代码的运行速度会更快，或者预计会以对数方式进行扩展。
无论如何，感谢您的见解。
答案 0 :(得分：0)
tl; dr：这是PageRank算法的一个固有限制，渐渐地说。
任何想要考虑所有边缘的算法都会有时间复杂度，即Omega（| E |）。任何试图测量全局拓扑属性的算法（例如PageRank等特征向量测量）都必须至少查看一次每个边缘。
通过更改Graph实现，您可以通过某些常量来提高性能，但最终在密集图上执行操作往往会很昂贵。
框架问题：图表的语义是什么，你希望通过什么来学习 计算PageRank？你想解决什么问题？