Startup/shutdown performance: unnecessary processing of activity events

[HeikoKlare]

Issue

The activity management in MutableActivityManager and ActivityPersistenceHelper is inefficient when dealing with higher amounts of activities. Activity enablements are unnecessarily processed and persisted upon different events:

1. All activities enablements are persisted upon every activity enablement change in the preference store, even if only the enablement of an expression-controlled activity changes (which is not part of the persisted states):
   

   eclipse.platform.ui/bundles/org.eclipse.ui.workbench/Eclipse UI/org/eclipse/ui/internal/ActivityPersistanceHelper.java

   Lines 60 to 62 in f4989c9

   	if (activityManagerEvent.haveEnabledActivityIdsChanged()) {
   	saveEnabledStates();
   	}

2. Enablement changes of expression-controlled activities are processed (and persisted as stated in 1.) even if the workbench is already closing. This has no effect as the activity support is disposed anyway during workbench close. Since the activity management is disposed after the service locator, which produces further events due to the evaluation service being removed, it receives and processes these additional events unnecessarily.

Reproduction

This unnecessary processing probably has no noticable effect in many products, as the types and amounts of activities are not high enough to produce a perceivable performance impact. In larger products this can, however, have severe impacts. In our product the effect is an overhead during startup and shutdown of the workbench of multiple seconds.

I have created a very artificial demo project with a large amount of defined activities and a large amount of enablement changes during startup/shutdown to make the impact obvious:

ManyActivitiesPerformanceDemo.zip

Evaluation

I have executed that demo with the current state of implementation and compared it to improved implementations that address the mentioned issue (can be seen in PR #1085 and #1086).

On my machine, the results with the demo project across several runs were as follows:

Startup time:
Without unnecessary persistence: 350-500 ms
With unnecessary persistence: 1500-1700 ms

Shutdown time:
With early disposal: 350-450 ms
Without proper disposal: 1300-1450 ms

How to proceed

I have started two PRs that address the mentioned issues (#1085, #1086). The changes of those PRs are the basis for the evaluation results mentioned above. In case you already see any side effects of addressing those issue that I am currently not aware of or, in general, reasons why the current behavior is required, I would be glad if you can let me know.