Steve Appling wrote:
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?
It should calculate a hash only when timestamp or length changes. Of
course, it may be broken ...
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.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
