-
Notifications
You must be signed in to change notification settings - Fork 189
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
Performance regression in 2.7.0 / 3.0.0 (maybe caused by #626?) #719
Comments
So I did some testing using 2.7.0 vs. 2.7.0 + reverted 774e135 from #626: Here are the numbers from the 2nd runs:
|
Can you set a breakpoints to see how many units are queried? I think we might use some caching because most of the units should be the same for all projects. |
… to classpath Currently a very simple approach is used that has a very bad runtime-complexity. This si now improved in the following way: - whether or not an IU is a fragment is cached - while iterating, matched fragments are removed - if the list of fragments is empty (all matched) break out the loop Signed-off-by: Christoph Läubrich <[email protected]>
… to classpath Currently a very simple approach is used that has a very bad runtime-complexity. This si now improved in the following way: - whether or not an IU is a fragment is cached - while iterating, matched fragments are removed - if the list of fragments is empty (all matched) break out the loop Signed-off-by: Christoph Läubrich <[email protected]>
… to classpath Currently a very simple approach is used that has a very bad runtime-complexity. This si now improved in the following way: - whether or not an IU is a fragment is cached - while iterating, matched fragments are removed - if the list of fragments is empty (all matched) break out the loop Signed-off-by: Christoph Läubrich <[email protected]>
Currently a very simple approach is used that has a very bad runtime-complexity. This si now improved in the following way: - whether or not an IU is a fragment is cached - while iterating, matched fragments are removed - if the list of fragments is empty (all matched) break out the loop Signed-off-by: Christoph Läubrich <[email protected]>
… to classpath Currently a very simple approach is used that has a very bad runtime-complexity. This si now improved in the following way: - whether or not an IU is a fragment is cached - while iterating, matched fragments are removed - if the list of fragments is empty (all matched) break out the loop Signed-off-by: Christoph Läubrich <[email protected]>
… to classpath Currently a very simple approach is used that has a very bad runtime-complexity. This si now improved in the following way: - whether or not an IU is a fragment is cached - while iterating, matched fragments are removed - if the list of fragments is empty (all matched) break out the loop Signed-off-by: Christoph Läubrich <[email protected]>
… to classpath Currently a very simple approach is used that has a very bad runtime-complexity. This si now improved in the following way: - whether or not an IU is a fragment is cached - while iterating, matched fragments are removed - if the list of fragments is empty (all matched) break out the loop Signed-off-by: Christoph Läubrich <[email protected]>
Currently a very simple approach is used that has a very bad runtime-complexity. This si now improved in the following way: - whether or not an IU is a fragment is cached - while iterating, matched fragments are removed - if the list of fragments is empty (all matched) break out the loop Signed-off-by: Christoph Läubrich <[email protected]>
I've noticed that in 2.7.0 the dependency and classpath resolution phases are slower than in 2.6.0.
For a non-parallelized build this adds about 7-10 minutes to our build time (727 artifacts):
2.6.0: ~ 25 minutes
2.7.0: ~ 35 minutes
I am currently trying to get some more concrete numbers with hot caches and populated ~/.m2/repository.
First bisecting show that this could be caused by #626.
The text was updated successfully, but these errors were encountered: