I'll send a snapshot to both of you off of the list. It looks to me like
40% of the time is spent in o.g.a.i.changedetection.CachingHasher.hash. That's
why I was thinking it was the up to date checks. How about an option to make
this just based on timestamp and length instead of hashing the contents?
Adam Murdoch wrote:
Steve Appling wrote:
After Hans' dependency resolution performance fix, the huge
performance problem we saw has been fixed (thanks Hans!). I still
find, however, that the overhead of all the up to date checking is not
worth it. When everything is up to date and there is nothing to do,
running "build -xtest" for our big project in the 0.8 version takes
about 1:11 (min:sec) and doing the same thing with the current trunk
version takes 1:24.
Is there a way to disable the up to date checks for particular tasks?
I don't think it is currently useful for compileJava or Copy type of
tasks and would like to try disabling it there.
How about we make the checking faster, instead? The new stuff has not
been heavily profiled or optimised. I was hoping to get back into making
this faster next week. I'm pretty confident we can get close for 'build
-x test'. Of course, plain 'build' should already be faster.
Of course, your numbers don't really say anything more than something is
slower in trunk. It could be anything, so let's measure before we
optimise. Any chance you could send me a profiling snapshot of the above
build. Or if not, I can add some logging and we can see where the time
is being taken.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
