Adam Murdoch wrote:
Steve Appling wrote:
I have been trying my company's build with the current main trunk, but
I'm seeing significant performance issues. I will try to run a
profiler and track this down more, but I wanted to see if this
triggered any thoughts for anyone.
I did fix a performance regression in trunk a day or so ago. I suspect,
however, this might be a different one.
I will try to reproduce it with the performance test project.
With 0.8, the subset of our build that was mainly compiling java and
jarring everything up took 3:23 (min:sec). With the current trunk, it
takes 15:34. I added a little bit of timing to the trace and at least
part of the problem is in the logic determining if a task is up to
date. ExecutionShortCircuitTaskExecuter line 58
(repositor.getStateFor) is taking over a minute to execute for some
tasks.
These performance problems seem to be worst for subprojects with deep
dependencies. The leaf subprojects (with no dependencies) seem to
execute as fast as before, but some of my root projects (lots of
dependencies) are very slow now.
Roughly how many is a lot of dependencies? Are they mainly project
dependencies, external dependencies?
I was mainly thinking about project dependencies. One of the projects that was
taking about 1:35 to determine if it was up to date has 12 direct compile
project dependencies. I'm not sure how to best determine the number of
transitive projects this ends up referencing, although there are a total of
about 50 projects used in this build. The dependencyReport for this project is
20,334 lines long.
From just trying a breakpoint a few times when it is running slowly,
it seems to often be inside a chain of dependency resolvers when I
think the problem is happening. Here is a typical stack trace:
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
