By cwebster on Sep 08, 2009
I had an opportunity recently to take a look at what was causing a significant increase in the time required for automated builds. The build system is based on Ant so what I wanted to see was a list of the top targets and sub tasks, so I could easily find the performance hotspots. I was hoping to use a performance flag that would generate this information but I didn't see anything readily accessible that would give me the information I needed.
After looking around the ant documentation, I found the BuildListener interface which provides notifications of build events (target started, target completed ...). What I wanted to do was to implement this interface to capture the starting and ending of tasks and targets so that I could generate an ordered list of the targets consuming the most time. I created a TimingBuildListener class that does the following:
- keep a list of the x targets that take the most time. Each target maintains the list of tasks (and their times) so that decomposition within a target is possible.
- manage the target lists according to the current stack of running targets.
- provide thread safety to work with the parallel task. There isn't as much documentation on how events are generated so this code was written empirically based on how Ant 1.7.1 is implemented and works for the intended project, so you may have different results.
Once I had this code, I got this working on a simple build file (adding a build listener only required adding the fully qualified classname of the listener using the -listener command line switch as well as the lib switch to specify the appropriate classpath for the class) and progressed to profiling the full build.
The profiling information identified a problem with the way we were compressing css and html files which was taking more than 50% of the build time (that includes unit tests), so we now get continuous build results in half the time