Community
Participate
Working Groups
I20100115-1100 The API builder performance is still bad for incremental build scenarios. Prior to API Tools, working with the Eclipse compiler was really slick, since everything was compiled as soon as you lifted your finger from Ctrl+S. But nowadays, API Tools is THE performance bottleneck that hits me literally every minute. E.g. right now, I'm in org.eclipse.ui.dialogs.FilteredItemsSelectionDialog.CamelCaseComparator.compare(Object, Object), and when I change '-1' to '-2' here, it takes 25s until the "incremental" build is done. For comparison, the same operation takes 4s when I disable the baseline (including Save Actions and the API tools builders). And this is with all the cached warmed up and using an SSD, not a floppy disk. Bug 233643 may have brought some improvements, but they are yet enough to bring me back to speed.
Created attachment 157694 [details] patch This patch improves incremental build performance as follows: * When API descriptions for source (workspace) types are updated, the description keeps track of whether it changed or not relative to the build being performed. * The build context now separates structural changes and description changes (as well as structural dependents and descriptoin dependents). The big difference is that when no API description changes, we no longer need to check the API use of dependent types. On the implementation side API description changes are detected using CRC codes assocaited with a relative build time (counter). When ever a description changes, it is updated to the current build time (count) of its project. The build can then safely discard description changes that occurred before the current build time, only considering those that changed during the current build. Running the existing performance tests, I did not see much difference (improvements). I need to write new tests that show when/how this approach wins - i.e. when there are no API description changes (the current tests include description changes/API use checks, so I would not expect them to change much).
>Running the existing performance tests, I did not see much difference >(improvements). Could you attach a patched plug-in, so that we could test it?
Created attachment 157842 [details] updated patch
Created attachment 157862 [details] updated patch
Created attachment 157967 [details] update Updated patch. Adds information to our build state to know when the build path of a project has changed. When the build path changes, we need to re-analyze dependents, since API descriptions of required projects/target platform may have changed.
Released to HEAD. Will continue to test in nightly builds.
Wow, that's amazing! I'm working with N20100202-2000 now, and speedup is incredible. And in the few cases I tested, it was also correct.
(In reply to comment #7) > And in the few cases I tested, it was also correct. I suppose we can make it even faster if correctness is not a priority.
Fixed. Please verify (peformance), Markus.
> Fixed. Please verify (peformance), Markus. Feels good in I20100209-2300, thanks.
