ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlton Brown" <>
Subject RE: Ivy Performance
Date Thu, 03 Sep 2009 14:40:40 GMT
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.

-----Original Message-----
From: Hans Dockter [] 
Sent: Wednesday, September 02, 2009 6:10 AM
Subject: Ivy Performance


I'm trying to improve the resolve performance of Gradle's usage of Ivy.

As a test I have an ivy module with three configurations (testRuntime  
extends testCompile extends compile).

As a comparison I use the following ant script:

<?xml version="1.0"?>
<project xmlns:ivy="antlib:org.apache.ivy.ant" name="sample"  
     <target name="resolve1">
         <ivy:resolve conf="compile" haltonfailure="false"/>

     <target name="resolve11" depends="resolve1">
         <ivy:resolve conf="compile" haltonfailure="false"/>

     <target name="resolve2" depends="resolve1">
         <ivy:resolve conf="testCompile" haltonfailure="false"/>

     <target name="resolve3" depends="resolve2">
         <ivy:resolve conf="testRuntime" haltonfailure="false"/>

     <target name="resolve4">
         <ivy:resolve conf="compile,testCompile,testRuntime"  

The Ant resolve seems to be smart in that it remembers earlier  
resolves. For example when executing resolve11 the second resolve is  
much faster than the first resolve. This is also true for resolves of  
extending configuration (e.g. resolve2 and resolve3).

The difference between resolve3 and the aggregate resolve4 is only 200  
ms in my example (1800ms vs 1600ms).

With Gradle the resolve performance of successive resolves seems not  
to benefit from earlier resolves. Unfortunately I was not successful  
yet to improve this behaviour. We use the same Ivy instance for  
successive resolves.

Where in Ivy does the optimization takes place? What can I do to  
switch this on?

Any help is very much appreciated

- Hans

Hans Dockter
Gradle Project Manager

This message and any attachment are confidential and may be
privileged or otherwise protected from disclosure and solely for
the use of the person(s) or entity to whom it is intended. If you
have received this message in error and are not the intended
recipient, please notify the sender immediately and delete this
message and any attachment from your system. If you are not the
intended recipient, be advised that any use of this message is
prohibited and may be unlawful, and you must not copy this
message or attachment or disclose the contents to any other person.

View raw message