Community
Participate
Working Groups
Last year we put in place the lazy loading of the registry in place. It was consisting in loading the configuration elements (children of extensions) on demand, once loaded the configuration elements were kept in memory ending up (in the worst case) with the complete registry loaded in memory. I tried an experiment that consisted in putting the configuration elements in a weakReference so that they can be GC'ed. Here are some results on an empty workspace for eclipse (I20040506). The second number in paranthesis is the number of instances with lazy loading only. # of strings: 28277 (4.5% less - 29607) # of config elements: 517 (74% less - 2248) # of config property: 1717 (78% less - 7420) Aside from the gain, the experiment revealed that even if some configuration elements are loaded several times on startup because they've been gc'ed, the degradation on the startup time is insignificant. I tried a startup of an empty workspace in an install that contains several hundreds of plugins and the results are the following: # of strings: 98241 (3.5% less - 101746) # of config elements: 946 (80% less - 5568) # of config property: 3341 (78% less - 17019) Java Heap size: 28192K (7% less - 30440) Java Heap Used: 17742K (7% less - 19163)
Created attachment 10513 [details] Patch the registry with weakReferences
The experiments needs to be confirmed on other scenarios, and some permutations of options should be tried out. Note that although the attached patch does not allow enablement/disablement of this feature, it can be done.
suggest you put in the option (with it on by default) to use weak references. We can pull it if needed but patching and building etc etc is likely to result in mistakes.
I released the code in HEAD. To disable this function, one can specify -Declipse.noRegistryFlushing=true on the command line. Instead of using the WeakReference, I used SoftReference which are supposed to be collected less eagerly.
