| Overview | For this release, we have focussed on improving the performance of AJDT builds, particularly incremental builds in multi-project settings. Most of our effort for this release has been towards ensuring efficiency in the core of AJDT. After upgrading to this release, you should notice that improvements in your build times for AspectJ projects. | ||||||||
|
| |||||||||
| Crosscutting model enhancements |
In this release, AJDT's internal representation of the crosscutting model has been made redundant and has been removed. The old way of doing things was that AJDT maintained its own copy of the model AspectJ was using internally for builds. And it was recreated from scratch after each successful build (both full and incremental builds, even if there were no changes!). The AJDT copy was more suitable for AJDT to work with when creating markers, populating views, etc. However, with some changes to AspectJ, the compiler's internal model has been modified to suit AJDT's needs directly--thereby removing any need for a duplicate model and saving memory and computation. There is a significant speed-up. The following numbers are the times for performing a full build of the workspace in a setting where there are 60 interrelated small AspectJ projects with some pervasive Aspects.
Note- average of 3 runs running on a Macbook 2.4 GHz Intel Core 2 Duo, 4GB ram. Unfortunately, in order to implement this improvement, we had to disable the crosscutting comparisons view, because it requires AJDT's specific crosscutting model. Our understanding is that this view was not used often, but if there is enough community interest, we will re-enable the feature. Our goal is to optimize for the common use case - and we believe that 90% of the time users will be doing quick edit/save/build cycles, rather than using views like the crosscutting comparisons view. |
||||||||
|
|
|||||||||
| Incremental build optimizations |
The second major improvement in this release has been improved performance during incremental builds. There is now more fine-grained communication between AJDT and AspectJ before incremental builds. Previously AspectJ did comprehensive analysis of the classpath, inpath, aspectpath, etc.--in order to determine what needed to be compiled. Even though AJDT already has precise knowledge of what the user had changed, there was no communications interface between AJDT and the compiler to transfer this information. Now before an incremental build, AJDT instead provides the compiler with specific information about what state has changed since the last successful build. And the compiler will then only do appropriate analysis. The following numbers show the times for making a whitespace change to a non-aspect java file in a project that 59 other projects depend on.
These number show the time to build after a change to a non-Java/AspectJ resource in a project that 59 other projects depend on:
These numbers illustrate the kinds of situations we are optimizing for in AJDT. These are situations where a programmer makes a small edit to a file and saves, and an incremental build is kicked off. We have tried hard to ensure that the time for an incremental build of this kind is fast enough so that programmers are not tempted to turn off Build automatically when editing AspectJ projects. |
||||||||
|
|
|||||||||
| Multi-threaded builds |
The final major improvement in this release is a multi-threaded build. Now, the essential part of the build (compilation) occurs in a single thread, and the more peripheral post build jobs (updating of gutter markers, and displaying error and warning messages) occur in separate threads. This frees the UI from sluggish builds and gives the user more control over the workspace. |
||||||||
|
|
|||||||||
| Bug fixes | |||||||||
|
|
|||||||||
| Previous Releases | See here for information on the new features in AJDT 1.6. | ||||||||