ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale Anson <dan...@grafidog.com>
Subject Re: Scanning Resource Collections Several Times
Date Fri, 21 Aug 2009 14:46:31 GMT
Hi Stefan,

Does your change improve performance of the delete task at all?  I 
recently replaced many of the calls to delete in our build files with an 
exec call to rm, since profiling showed the delete task was responsible 
for over 50% of the total time of the build.  Part of the problem is the 
way delete is implemented in Java itself, that is, a non-empty directory 
cannot be deleted with java.io.File.delete(), so the delete task is 
required to traverse the tree and delete files from the bottom up. 

Dale


Stefan Bodewig wrote:
> On 2009-08-21, Matt Benson <gudnabrsam@yahoo.com> wrote:
>
>   
>> --- On Fri, 8/21/09, Stefan Bodewig <bodewig@apache.org> wrote:
>>     
>
>   
>>> I'd like to modify Resources to
>>>       
>
>   
>>>  (1) lazily initialize size() - Delete never asks for it, for
>>>      example.
>>>       
>
>   
>> Sounds good.
>>     
>
>   
>>>  (2) Cache the remaining iteration results when initializing size
>>>       
>
>   
>> The only thing that concerns me about this is the fact that I did make
>> 'cache' an attribute on BaseRC because I thought there might be times
>> caching was not wanted.
>>     
>
> There sure is, there are usecase where you want to see changes made
> during the build reflected in resource collections used via id.
>
>   
>> How would one defeat caching of <resources>?
>>     
>
> Currently you only get cached results when size() has been invoked.  In
> the same case the result of size() would have been cached before (and
> potentially wrong).
>
> You are correct, it would be a better option to give explicit control
> over caching (even make it false by default, since this is what we've
> had in 1.7.1) and explicitly enable it in cases where Resources is used
> inside of tasks (not passed around as a datatype) like in Delete.
>
> I'll adapt to that.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message