Speed cycle checking. #1
Open
Conversation
This file contains 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
When run on a codebase with a large dependency tree the cycle checking can take an enormous amount of time. In my tests, attempting to make JOM work with ghostscript's makefiles, it can basically take forever (I gave up after 10 minutes). There is a simple fix for this, implemented here. Once we have cycle checked downwards from a given node, we know that whenever we reach that node again, we need not bother to recheck it as the results will be no different. Hence whenever we successfully return from the recursive call, set a flag meaning "NoCyclesRootedAtThisNode". Whenever we step into a node, if that flag is set, there is no need to recurse at all. This is sufficient to make the cycle checking instant for the Ghostscript makefiles. This does mean that we are left with a 'dirty' tree, in that the NoCyclesRootedAtThisNode flags are left set. I don't think this is an issue, (does Parser:apply ever get called more than once? And if it does, might the tree have changed between calls?) but just in case, I have introduced another pass where we run through the tree clearing the nodes.
There is no point in repeatedly traversing downwards from a node once we've constructed the rules for it. If a node has rules, just exit. This vastly speed the time spent on complicated Makefiles like Ghostscript.
|
Thanks for your contribution! You may close this merge request. |
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When run on a codebase with a large dependency tree the cycle checking can take an enormous amount of time.
In my tests, attempting to make JOM work with ghostscript's makefiles, it can basically take forever (I gave up after 10 minutes).
There is a simple fix for this, implemented here. Once we have cycle checked downwards from a given node, we know that whenever we reach that node again, we need not bother to recheck it as the results will be no different.
Hence whenever we successfully return from the recursive call, set a flag meaning "NoCyclesRootedAtThisNode". Whenever we step into a node, if that flag is set, there is no need to recurse at all.
This is sufficient to make the cycle checking instant for the Ghostscript makefiles.
This does mean that we are left with a 'dirty' tree, in that the NoCyclesRootedAtThisNode flags are left set. I don't think this is an issue, (does Parser:apply ever get called more than once? And if it does, might the tree have changed between calls?) but just in case, I have introduced another pass where we run through the tree clearing the nodes.