Skip to content

Optimize diameter calculation for weighted graphs#495

Open
LoveLow-Global wants to merge 13 commits intoJuliaGraphs:masterfrom
LoveLow-Global:optimize-diameter-2
Open

Optimize diameter calculation for weighted graphs#495
LoveLow-Global wants to merge 13 commits intoJuliaGraphs:masterfrom
LoveLow-Global:optimize-diameter-2

Conversation

@LoveLow-Global
Copy link
Contributor

This edit will be the extension of the pull request about two months ago. At the time, the iFUB algorithm was only applied to unweighted graphs, but now it is implemented to weighted graphs as well.

To compare with the original method of using diameter(eccentricities::Vector) = maximum(eccentricities), I have added a testset called "Weighted Diameter Benchmarks" under test/distance.jl. This should be removed before merging.

According to the Benchmarks mentioned above, this implementation makes diameter calculation of real-world like graphs (when tested on Barabási-Albert Model) over 50 times faster, and diameter calculation on random graph models (when tested on Erdős-Rényi Graph) over 2 times faster. This happens because the algorithm is more useful when some vertices have very high degrees.

@github-actions
Copy link
Contributor

github-actions bot commented Feb 22, 2026

Benchmark Results (Julia v1)

Time benchmarks
master 8e90aa0... master / 8e90aa0...
centrality/digraphs/betweenness_centrality 16.5 ± 0.74 ms 16.3 ± 0.48 ms 1.02 ± 0.055
centrality/digraphs/closeness_centrality 11.7 ± 0.6 ms 12.1 ± 0.73 ms 0.966 ± 0.076
centrality/digraphs/degree_centrality 2.05 ± 1.8 μs 2.06 ± 1.8 μs 0.995 ± 1.2
centrality/digraphs/katz_centrality 0.861 ± 0.077 ms 0.872 ± 0.081 ms 0.988 ± 0.13
centrality/digraphs/pagerank 0.0362 ± 0.0054 ms 0.0364 ± 0.0054 ms 0.995 ± 0.21
centrality/graphs/betweenness_centrality 28.9 ± 1.2 ms 28.5 ± 1.2 ms 1.01 ± 0.062
centrality/graphs/closeness_centrality 21 ± 0.19 ms 21 ± 0.23 ms 0.998 ± 0.014
centrality/graphs/degree_centrality 1.53 ± 0.19 μs 1.48 ± 0.16 μs 1.03 ± 0.17
centrality/graphs/katz_centrality 1.02 ± 0.063 ms 1.04 ± 0.043 ms 0.977 ± 0.072
connectivity/digraphs/strongly_connected_components 0.0435 ± 0.0014 ms 0.0433 ± 0.0012 ms 1 ± 0.042
connectivity/graphs/connected_components 24.5 ± 0.72 μs 24.2 ± 0.67 μs 1.01 ± 0.041
core/edges/digraphs 7.83 ± 0.11 μs 7.02 ± 0.01 μs 1.11 ± 0.016
core/edges/graphs 17 ± 0.081 μs 15.7 ± 0.18 μs 1.08 ± 0.013
core/has_edge/digraphs 5.2 ± 0.38 μs 5.19 ± 0.36 μs 1 ± 0.1
core/has_edge/graphs 5.55 ± 0.41 μs 5.62 ± 0.42 μs 0.988 ± 0.1
core/nv/digraphs 0.361 ± 0.01 μs 0.361 ± 0.011 μs 1 ± 0.041
core/nv/graphs 0.381 ± 0.01 μs 0.39 ± 0.01 μs 0.977 ± 0.036
edges/fille 8.22 ± 0.97 μs 7.95 ± 0.89 μs 1.04 ± 0.17
edges/fillp 5.05 ± 4 μs 5.46 ± 5.1 μs 0.925 ± 1.1
edges/tsume 2.47 ± 0.021 μs 2.69 ± 0.04 μs 0.921 ± 0.016
edges/tsump 2.56 ± 0.1 μs 2.47 ± 0.021 μs 1.03 ± 0.042
insertions/SG(n,e) Generation 24.6 ± 3.9 ms 24.9 ± 3.8 ms 0.988 ± 0.22
parallel/egonet/twohop 0.285 ± 0.0014 s 0.303 ± 0.0097 s 0.941 ± 0.031
parallel/egonet/vertexfunction 2.22 ± 0.11 ms 2.33 ± 0.18 ms 0.952 ± 0.087
serial/egonet/twohop 0.289 ± 0.0021 s 0.316 ± 0.016 s 0.914 ± 0.045
serial/egonet/vertexfunction 2.26 ± 0.11 ms 2.19 ± 0.084 ms 1.03 ± 0.064
traversals/digraphs/bfs_tree 0.0493 ± 0.0091 ms 0.0528 ± 0.0089 ms 0.933 ± 0.23
traversals/digraphs/dfs_tree 0.0637 ± 0.0096 ms 0.067 ± 0.01 ms 0.951 ± 0.2
traversals/graphs/bfs_tree 0.0528 ± 0.0021 ms 0.056 ± 0.0019 ms 0.942 ± 0.049
traversals/graphs/dfs_tree 0.0657 ± 0.0031 ms 0.0685 ± 0.0026 ms 0.959 ± 0.058
time_to_load 0.543 ± 0.0036 s 0.555 ± 0.0029 s 0.978 ± 0.0082
Memory benchmarks
master 8e90aa0... master / 8e90aa0...
centrality/digraphs/betweenness_centrality 0.29 M allocs: 24 MB 0.29 M allocs: 24 MB 1
centrality/digraphs/closeness_centrality 18.6 k allocs: 14.5 MB 18.6 k allocs: 14.5 MB 1
centrality/digraphs/degree_centrality 8 allocs: 5.01 kB 8 allocs: 5.01 kB 1
centrality/digraphs/katz_centrality 2.63 k allocs: 2.83 MB 2.63 k allocs: 2.83 MB 1
centrality/digraphs/pagerank 21 allocs: 14.9 kB 21 allocs: 14.9 kB 1
centrality/graphs/betweenness_centrality 0.545 M allocs: 0.0313 GB 0.545 M allocs: 0.0313 GB 1
centrality/graphs/closeness_centrality 19.3 k allocs: 14 MB 19.3 k allocs: 14 MB 1
centrality/graphs/degree_centrality 10 allocs: 5.43 kB 10 allocs: 5.43 kB 1
centrality/graphs/katz_centrality 2.96 k allocs: 3.1 MB 2.96 k allocs: 3.1 MB 1
connectivity/digraphs/strongly_connected_components 1.05 k allocs: 0.075 MB 1.05 k allocs: 0.075 MB 1
connectivity/graphs/connected_components 0.061 k allocs: 22.5 kB 0.061 k allocs: 22.5 kB 1
core/edges/digraphs 3 allocs: 0.0938 kB 3 allocs: 0.0938 kB 1
core/edges/graphs 3 allocs: 0.0938 kB 3 allocs: 0.0938 kB 1
core/has_edge/digraphs 20 allocs: 12.6 kB 20 allocs: 12.6 kB 1
core/has_edge/graphs 28 allocs: 13.8 kB 28 allocs: 13.8 kB 1
core/nv/digraphs 3 allocs: 0.0938 kB 3 allocs: 0.0938 kB 1
core/nv/graphs 3 allocs: 0.0938 kB 3 allocs: 0.0938 kB 1
edges/fille 3 allocs: 0.153 MB 3 allocs: 0.153 MB 1
edges/fillp 3 allocs: 0.153 MB 3 allocs: 0.153 MB 1
edges/tsume 0 allocs: 0 B 0 allocs: 0 B
edges/tsump 0 allocs: 0 B 0 allocs: 0 B
insertions/SG(n,e) Generation 0.0465 M allocs: 10.9 MB 0.0465 M allocs: 10.9 MB 0.997
parallel/egonet/twohop 10 allocs: 0.0768 MB 10 allocs: 0.0768 MB 1
parallel/egonet/vertexfunction 10 allocs: 0.0768 MB 10 allocs: 0.0768 MB 1
serial/egonet/twohop 3 allocs: 0.0764 MB 3 allocs: 0.0764 MB 1
serial/egonet/vertexfunction 3 allocs: 0.0764 MB 3 allocs: 0.0764 MB 1
traversals/digraphs/bfs_tree 2.34 k allocs: 0.113 MB 2.34 k allocs: 0.113 MB 1
traversals/digraphs/dfs_tree 2.44 k allocs: 0.118 MB 2.44 k allocs: 0.118 MB 1
traversals/graphs/bfs_tree 2.52 k allocs: 0.121 MB 2.52 k allocs: 0.121 MB 1
traversals/graphs/dfs_tree 2.63 k allocs: 0.127 MB 2.63 k allocs: 0.127 MB 1
time_to_load 0.145 k allocs: 11 kB 0.145 k allocs: 11 kB 1

@codecov
Copy link

codecov bot commented Feb 22, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.31%. Comparing base (ca5cbc3) to head (8e90aa0).

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #495      +/-   ##
==========================================
+ Coverage   97.27%   97.31%   +0.03%     
==========================================
  Files         126      126              
  Lines        7674     7739      +65     
==========================================
+ Hits         7465     7531      +66     
+ Misses        209      208       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@Krastanov
Copy link
Member

We now have a benchmarks file and as you can see it is executed in each PR. Could you add a (fairly small, fast) benchmark to that file? Both of the slow approach and of the new approach (I understand the API for the new approach would be the "slow approach" until this is merged)?

@LoveLow-Global
Copy link
Contributor Author

Hello, thanks for the feedback. I am not sure if I have understood your feedback, but I have moved the benchmarking part in test/distance.jl to the benchmark section.

@Krastanov
Copy link
Member

One more thing and this is probably good to go. I poorly understood how you had structured the tests. It is good that you have added the benchmarks, they are useful and this is a good place for you. But in fulfilling my poorly phrased request, I think you have completely removed any tests for this algorithm on weighted graphs. Could you, in addition to the benchmarks, also add correctness tests to the test suite, even if code-wise they are very similar.

@Krastanov
Copy link
Member

Oh, and I started keeping a CHANGELOG -- could you add an entry in it as well?

@LoveLow-Global
Copy link
Contributor Author

I have edited the codes and added a line on CHANGELOG, I hope this looks okay.

Also, if Graphs.jl now uses a benchmark section, I believe changes to lines 83-139 in test/distance.jl can be made, as it contains codes that compare with the original (naive) method of calculating diameters for unweighted graphs. That part in test/distance.jl was added around 2 months ago, when I first applied this algorithm only on unweighted graphs.

@Krastanov
Copy link
Member

I used Opus 4.6 to generate a bunch of edge-case tests and I think it found a broken edge case. The prompt was this: "In Graphs.jl PR 495 a new algorithm is being implemented. Review it, especially focusing on edge cases. Locally generate and run additional tests in order to try to detect bugs, including commond graphs, random graphs, graphs with self-loops, empty graphs, and other edge cases."

Could you please check the PR towards your own branch (LoveLow-Global#1) with the suggested new tests and (in a separate commit) the potentially wrong edge-case fix. I do not particularly trust Opus to do this correctly, but I am stretched pretty thin and can not commit to doing a more detailed review (I apologize for this review asymmetry -- I know it is frustrating but we simply do not have enough reviewers right now).

I think the bug that Opus found is real, I am not at all trusting of its potential fix.

Speaking of which, given the struggles Graphs.jl has with getting enough maintainers, and your already significant contributions, do let me know if you are interested in helping with the occasional code review -- even once or twice a year can be very valuable for the community.

Thanks again for your submission!

@Krastanov
Copy link
Member

Also, to clarify -- no need to accept the PR from Opus at all! This is your code and it is much better than what Opus does. The PR was created just so that you can see the tests for yourself and what is the failing one and what is the guessed source of the failure.

@LoveLow-Global
Copy link
Contributor Author

Thanks for the comment and the PR, I will try to investigate on the BUG on Asymmetric weights on undirected graph. Also please note that I am very busy this week, and I may not be able to properly review the PR on my branch until this weekend.

@Krastanov
Copy link
Member

No worries,we are all volunteers here!

@LoveLow-Global
Copy link
Contributor Author

Hello, sorry for taking so long.
I believe the bot has done its job well, it pointed out the thing which I overlooked. I fixed the code, it will not have that issue anymore. Thank you.
Also, I would like to tell you that I would be interested in helping with the occasional code review, although I am not sure how much I would be helpful.

@LoveLow-Global
Copy link
Contributor Author

If we have to talk in more detail regarding on being code reviewer, please email me. My email address can be found on my profile. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants