trying to write an ant profiler. His preliminary results are
encouraging but I believe he’s only solved the easy problem.
In my experience, ant builds are not slow because they spend too
much time in targets (this time is usually incompressible) but because identical
targets get run multiple times or or the same files get processed several times.
Here are a few steps that might lead to a good ant profiler:
- Provide a way to visualize the graph of dependencies.
should be easy enough: parse all the targets and their depends
clauses and show a graphical view of what it looks like. With some
simple graph algorithms, it’s also pretty easy to point out extraneous and
- Add finer-grained support in ant‘s listeners.
This requires active participation from the ant project but I think it would
be worth it. The
current listeners are fairly primitive and do not provide any insight on
the internals of each task. What I believe would be interesting is for
each task to implement an interface that lets observers know when a certain
file is being processed and when the resulting file is starting and
finishing to be generated. With support for such listeners, it would
be trivial to see that the file "A.java" is being processed twice even in
the most complex builds.
- Start identifying a few "ant build anti-patterns" (targets
and depends that create extra work)
When I looked for examples of
anti-patterns in my various builds, I came up empty. It’s not that my
build files are good (I know they’re not), but it just seems very hard to
pinpoint exactly what goes wrong as your build files start accreting fat
Also, there are two different ways we can derive information from this
stage: a) by looking at the build.xml (or its DOM
representation) directly or b) at runtime, by storing information on the
target paths that are being walked by ant and displaying a report at the end.
Can you think of any ant design anti-pattern that will cause a build to take
longer than it should?