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. Cheers, Colin 2008/11/19 Benjamin Damm <[EMAIL PROTECTED]> > 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 >
