Community
Participate
Working Groups
This bug is keeping track of project model optimizations. See AspectJ bug 243376 and bug 249216 and bug 247742. Already commited to cvs is a fairly large undertaking that has refactored the way the AspectJ project model is created and stored. The over arching goal has been to minimize the time spent in AJBuilder for incremental builds. As I will describe later, this has been quite successful. Prior to the refactoring, after every build AJDT would ask the compiler for its project model (ie- the crosscutting relationships) and then AJDT would generate its own project model using IJavaElements. This is redundant AJDT can use AspectJ's project model as long as there is a good mechanism to translate between the two areas. This refactoring has focused on ensuring that AJDT can use AspectJ's project model. In AspectJ, this consists of a program element hierarchy (in the IHierarchy object) and a relationship map (the RelationshipMap object). Both objects refer to IProgramElement objects based on a string handle identifier, which uniquely identifies the element. This handle identifier is similar to the handle identifier used by IJavaElements in jdt. (It is not identical for some corner cases as described in bug 247742.) Most of the logic to translate from IJavaElements to IProgramElements exists in the AJProjectModelFacade class. IJavaElements are created using the methods JavaCore.create, AspectJCore.create, and IJavaElement.getHandleFromIdentifier. I put a lot of effort into refactoring these methods (or at least those methods that are part of AJDT) to ensure that they work in similar ways to their JavaElement counterparts. As such, I was able to delete a lot of code, most notably, the AJProjectModel and AJModel classes are now gone. They are replaced by AJProjectModelFacade and AJPRojectModelFactory. MockXXXElement classes are gone (except for MockSourceMethod). Also, BinaryWeavingSupport is now gone.
Created attachment 114048 [details] Spreadsheet that shows some statistics on build times for before and after the refactoring This spreadsheet contains two columns of numbers. The first column has the build times for the non-optimized project model. The second column contains the build times for the optimized project model.The target of the tests is the Spring DM Server.The first 4 rows show the numbers for full builds of the server (in seconds). You can see that in most cases the optimized version is about 15 seconds faster (or 25% faster).The next group of rows show the time to rebuild after a whitespace change on a single file. Here you can see that the optimized version is about 3x faster than the non-optimized version. The numbers are broken down into time spent in AJDE (that is, the compiler iteself), building the project model (in the non-optimized version only since the optimized version does not build a separate project model), and AJBuilder which is the total time spent on the entire build (and includes the other two numbers). The final section shows the time for a complete rebuild of a single project. Again, you can see that the project model optimizations speed up the build process by a factor of about 3.
Finally, here is a list of things that have been disabled because of the new project model. 1. Persisting of the project model. This should not be too hard to do since the AspectJ relationship map is serializable. It is just not something we have worked on yet. The ramifications of this is that the crosscutting view, and navigation between related elements cannot happen until there is a build. 2. Crossscutting comparisons. Disabled because the model is not serializable. This is not a feature that is widely used. If requested, I will look into reinstating this feature. 3. Navigating from elements on the aspect path. Gutter markers used to be applied to aspects on the aspect path, but the new way of producing markers does not place markers on these kinds of aspects. It is possible, but would be necessary to do lots of record keeping to make sure that these markers are deleted properly.
done
