Community
Participate
Working Groups
DDW (03/10/2001 10:34:33 AM) In 202a, some timings were done to get a feel for how caching the plugin registry would affect startup times. The following data shows how long it took to "parse and resolve" the plugin registry and the corresponding full startup times vs. how long it took to read the plugin registry from a cache file and the corresponding full startup times. Coincidentally,these tests were run over 2 environments. The first environment contained one java project and one plugin project (with one plugin with errors). The plugin project was open. The second environment contained only one java project with 3 simple class files all of which were open. It was noticed that when the environment with the plugin project was used, initial startup contained an extra call to parse a registry. Comparing groups 1 and 3, the full startup times seem larger with the plugin project while the times for parsing and resolving the plugin registry seem comparable. The times for reading the plugin registry from a cache file in groups 2 and 4 are similar but the startup times are quite different. Group 1: Parse and Resolve (with 2 projects: 1 java project + 1 plugin project with errors) 6679 ms f ull startup = 27036 ms 6709 ms 26936 6649 27066 6789 28271 7124 30799 ------------------------------------------ 6790 28021.6 (AVERAGE) Group 2: Cached Registry (with same 2 projects) 421 25069 391 24537 401 24948 391 24547 390 24978 ------------------------------------------ 398.8 24815.8 (AVERAGE) Group 3: Parse and Resolve (with 1 java project) 6660 22764 6740 22724 6650 22674 6640 22674 6670 22635 6581 23337 ------------------------------------------ 6656.8 22801.3 (AVERAGE) Group 4: Cached Registry (with 1 project - the java project) 391 17014 401 16853 401 16944 391 16834 391 16913 ------------------------------------------ 395 16911.6 (AVERAGE) NOTE: In the first two groups (the ones with the 2 projects), there was some other xml parsing done (the RegistryLoader gave a time for a 'Parsed Registry'). In the first group (when we were doing the Parse and Resolve of the 'real' registry) the times for this 2nd parse were about 801 ms. When we cached the 'real' registry, the times for the 2nd parse were up significantly to over 4000 ms!! This 2nd parse was missing from the 3rd and 4th group of data (the ones without the plugin project). NOTES:
PRODUCT VERSION: 202a
Moving to PDE UI.
Since majority of the users will use the default settings (which means working against plug-ins in the Eclipse product they run PDE in), we can safely use the live registry to initialize (since that is what the default is). Live registry has already been parsed and resolved. All that PDE needs to do is walk it and create its own models out of it.
The load times for non-default settings (when using one Eclipse version to develop against another) will be more-less the same. However, this becomes less of a problem because these cases are less frequent.
