Boris wrote: > I have written a blog post about the bloat topic: > http://borisoneclipse.blogspot.com/2008/10/avoiding-bloat.html <http://borisoneclipse.blogspot.com/2008/10/avoiding-bloat.html>
Great posting! It inspired me to think about another potential reason for bloat: duplication of graphics, images and NLS Strings We do have ISharedImages, but more often than not a plugin is forced to duplicate some image or resource String because the original owner of that image or String is (rightfully) hiding that resource and doesn't want to expose it as API. But isn't that a development-time / installation-time restriction only? Why do we need to bother the plugins at runtime with duplicates of the same Strings and images getting loaded into Memory, in multiple ImageRegistries etc... I'd not be surprised if we could get rid of a good deal of the "Running out of PermGen Space" issue with a different approach to loading Images and Strings at runtime. I'm thinking about a SINGLE ImageRegistry / StringRegistry (could also be a database), from which plugins can acquire an image/String by means of a Key (that could be an int number, for instance). At the time a bundle is installed, all its images / Strings are placed into the common Database. Clients get a Key in return, which they can use at runtime to retrieve their data. Identical data is collapsed. Sounds interesting? Or am I missing something? Uninstalling a bundle would certainly not be easy, and I guess that the String and Image database would likely be an add-only thing to avoid lifecycle issues. I think we should work on the Wiki pages, adding additional ideas for reducing Bloat as we find them. I'm just struggling to find time for that... Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
