You may have a look to https://issues.apache.org/jira/browse/IVY-872 where some of the performance optimization have been implemented.
Gilles Scokart 2009/9/3 Hans Dockter <[email protected]> > > On Sep 3, 2009, at 4:40 PM, Carlton Brown wrote: > > The resolve task actually fetches artifacts into the local cache, so you >> would expect subsequent resolves of the same configuration to be much >> faster (likewise with extended configurations, if they are not too >> disjoint from the base configuration). >> >> If you observe that subsequent resolves don't benefit from previous >> ones, it sounds as if you're somehow circumventing the cache >> mechanism... perhaps defeating its effectiveness by setting the >> useOrigin attribute, using a TTL, cleaning the cache between each >> resolve, or using a distinct cache for each resolve. None of these >> behaviors are enabled by default. >> >> I'd check the state of the cache after each resolve... if it isn't >> getting populated with artifacts, or if it's getting wiped entirely, >> there's your problem. >> > > Thanks for your reply. I should have mentioned that all artifacts are in > the cache and are retrieved from the cache. But a resolve from a cache also > easily takes more than a second. In the case of a second Ant Ivy resolve > this number shrinks in our examples to something like 200ms. Therefore I was > wondering what optimization is taking place here and how to use this for our > build system. > > > - Hans > > -- > Hans Dockter > Gradle Project Manager > http://www.gradle.org > > >
