ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Fleming" <>
Subject Re: Speeding up ivy:resolve
Date Wed, 19 Nov 2008 19:12:34 GMT
Hi Ben,

I'd be interested, for sure. We have about 190 modules in our project now
and resolve is a large part of our build time. I've been meaning to look
more closely at it for ages now, but I'm totally swamped.

One thing I did see when I profiled our build a while back was that
somewhere in the depths there (I can't remember the exact spot, sorry) Ivy
calls getHostName() and doesn't cache the return value. This ends up being
called a lot of times (I don't remember the exact number but IIRC in the
thousands) due to recursive resolves, and would be a two-line fix. I suspect
this is the cause of a wide variation in our build times across different
machines that we're seeing (particularly that builds take much longer in our
integration server).

If I get a moment I'll profile our build again (easy because it's written in
Java) and post any relevant info here.


2008/11/19 Benjamin Damm <>

> Hi,
>  Does anyone have or would anyone be interested in a caching facade to
> speed
> up ivy:resolve?  I have a case where my project has about 100 modules in a
> few different configurations and it is taking a little longer to do the
> resolve than I can stand.  I'm concerned about what will happen when I
> introduce NFS into the mix.  For these reasons I'm considering what options
> I
> may have for caching the ivy:resolve (if this is possible) by perhaps
> storing
> structures to disk in a file that can be updated (perhaps by deleting it,
> I'm
> not sure yet).
>  The difference between this cache and the ivy cache is I'm not copying the
> files out of their locations; where they are presently is just fine because
> the entire repository is on local disk (and managed by p4).  So really this
> comes down to speeding up the filesystem resolver.
> -Ben
> --
> Benjamin Damm
> Silver Spring Networks
> 650-298-4200 x201

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message