-
Notifications
You must be signed in to change notification settings - Fork 308
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GoMod: Fix the algorithm for handling cycles #5628
Conversation
Codecov Report
@@ Coverage Diff @@
## main #5628 +/- ##
============================================
+ Coverage 67.83% 67.90% +0.06%
+ Complexity 2177 2164 -13
============================================
Files 271 271
Lines 15854 15863 +9
Branches 2809 2823 +14
============================================
+ Hits 10754 10771 +17
+ Misses 3967 3957 -10
- Partials 1133 1135 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
effa5f9
to
ec1d003
Compare
Thanks @fviernau!, is there an issue already created to "refactor GoMod to |
Tested the analyze tool with the Scorecard repo and works fine without the need of adding extra memory 👌 |
ec1d003
to
3f9e8a6
Compare
3f9e8a6
to
69de79a
Compare
The previous algorithm exhibits the following issues when run on graphs with cycles, in particular when the amount of edges is large: 1. Cycles of length 1 lead to infinite recursion. 2. The algorithm is inefficient in terms of execution time and memory allocation, as it creates a copy of the `predecessorNodes` set per recursion. 3. When run against [1] the execution of `toPackageReferenceForest()` didn't finish within 15 minutes, causing high CPU load and memory consumption. If GoMod used the dependency graph format already, the solution would be as simple as calling `DependencyGraphBuilder.breakCycles()`. Fix the problem by copying the code of `DependencyGraphBuilder.breakCycles()` as a temporary quick fix. This saves effort, because refactoring GoMod to use the dependency graph is planned anyway [2], which will allow for removing that copied code again. [1] https://github.com/ossf/scorecard [2] #4249 Fixes #5627. Signed-off-by: Frank Viernau <[email protected]>
69de79a
to
1467603
Compare
The previous algorithm exhibits the following issues when run on graphs
with cycles, in particular when the amount of edges is large:
allocation, as it creates a copy of the
predecessorNodes
set per recursion.toPackageReferenceForest()
didn't finish within 15 minutes, causing high CPU load and memory
consumption.
If GoMod used the dependency graph format already, the solution would be
as simple as calling
DependencyGraphBuilder.breakCycles()
. Fix theproblem by copying the code of
DependencyGraphBuilder.breakCycles()
asa temporary quick fix. This saves effort, because refactoring GoMod to
use the dependency graph is planned anyway [2], which will allow for
removing that copied code again.
[1] https://github.com/ossf/scorecard
[2] #4249
Fixes #5627.