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 <gudnabr...@yahoo.com> wrote:
--- On Fri, 8/21/09, Stefan Bodewig <bode...@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-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
