ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Reilly" <>
Subject Re: path performance
Date Wed, 18 Oct 2006 16:41:31 GMT
On 10/18/06, Kevin Cline <> wrote:
> On 10/18/06, Dominique Devienne <> wrote:
> >
> > > Timing indicates that ant is spending 30 seconds per test to walk the
> > lib
> > > tree building the classpath.  Does anyone have a solution to this
> > problem?
> >
> > Frankly, that sounds a bit fishy ;-)
> Unless your hierarchy is
> > exceedingly large in ${lib.dir}, it's unlikely it's the fileset scan
> > that's taking so long. I'd write a build file that only defines the
> > <fileset>, then <pathconvert>s it and <echo>s it, with timestamps
> > around to find out for sure how long is the scan.
> Thanks for the suggestion. I did that, and it really does take that long.
> The JARs are stored remotely in a Clearcase VOB, so that slows things down a
> bit.  Still, I don't understand why the fileset scan takes 30 seconds, while
> the native find command does the same thing in under 2 seconds.

The java code (or at least AntClassLoader) opens the file and reads
in the Manifest, the classloader needs to read in the class files from
the zip file as well.
I would suggest that you copy the jar files from the VOB to a local directory
using the <copy> task (this will mean that as the VOB jars change
the copy task will copy the changed files) and use this directory for
testing with.
Another sugestion would be to use <junit fork="yes" forkmode="once">

>  I'm pretty new to Java development.  Is Java really that much slower than
> native code?
Initial class loading is slow - about 0.2 - 1 second depending on
the number of classes that are loaded, after that it depends.

> We're currently using the 1.4.2 SDK.  Will it be any faster
> when we migrate to 1.5?
> Could be that you have fork="true" on JUnit, and the overhead of
> > starting a new VM and/or the test infrastructure is to blame???
> That's definitely not it.
> Is the scan really is that slow, then you could expand once all
> > jars/zips in a single dir, and use that dir on the classpath (and/or
> > create an uber-jar of this dir).
> We're using a number of libraries that are currently under development, so
> we couldn't do this just once and forget about it.  I think I'm going to try
> to change so that it only scans
> once, instead of scanning every time it is used.  If that works I'll post it
> to the Ant development list.
> a LOT of JARs is too vague I guess. Do the self-contained timing test
> > above, and give us some more indication as to what LOT means in this
> > case. --DD
> A lot = 102.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message