| [aspectj-users] Reduced compile times for AspectJ-1.2 |
In preparation for AspectJ-1.2, I've been working on reducing the compile times for AspectJ. In particular, I've been attacking the time to weave advice. This round of optimizations can reduce compile times by about 2-4X. We expect to make nightly builds available within the next week to people who want to start testing early versions of 1.2. Details: The attached graph shows the amount of time that weaving adds to a pure Java compile as a fraction of the pure Java compilation time. These numbers are based on a benchmark written by Noel Markham with input from Matthew Webster and myself (see org.aspectj.ajdt.core/testsrc/RunWeaveTests.java). The different columns measure advice that applies to different sets of join points. For these results, the base system has 125 classes with 100 methods of 10 lines each (125KLoC). There are two groups of pointcuts. The first group applies only to execution join points and the second only to field gets. Within each group of pointcuts, there are three versions. The first only applies to bytecode in a single class and should be easy to handle with a fast match. The second version also can only apply to bytecode in a single class, but it should require more work from the matcher to determine this. The third version actually applies to all of the corresponding join points -- this version does a lot of work and we expect it to take some serious time. The across-the-board performance gains came from a combination of removing some very expensive debugging code and from Erik Hilsdale's "bug-fix" to bcel for a Locale bug that as a side-effect of Erik's offended design aesthetic removed a lot of slow reflective code used to generate instruction lists. The additional performance gains for the execution-based tests came from an optimization to detect the cases where no shadow mungers could match join points in the body of a method and if so to not generate all of the shadows for the body. It's interesting that this can be almost as fast as the simple fast-match speed-up in the first case. There's always more performance work to be done but this should be a nice improvement for the AspectJ-1.2 release. Jim Hugunin - http://hugunin.net
Attachment:
bench1.gif
Description: Binary data