Optimize degeneracy ordering #108
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- calculate the updated degrees and update the node-deg map in a single pass - remove an unused loop parameter
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was finding
loom.alg/degeneracy-orderingwas running a bit slowly on a dense graph, so have had a go at speeding it up. This version calculates the updated degrees and updates the node-degree map in a single pass. I also removed an unused loop parameter and added a comment since the code is a bit more concise now.This is the graph I was struggling with: https://gist.github.com/cbowdon/7711151498464be7a25e965497edb1c2
On my weeny laptop the version in this PR completes in 50 milliseconds whereas the original version takes at least 15 minutes (I gave up waiting) on OpenJDK 8.
lein test-allstill passes.Edit: It turns out my graph had a node with an edge to itself, which was causing an infinite loop in the original implementation. After removing this edge the original version completes in 80 ms, so only a minor improvement in normal cases. Both versions return the same result.