Whow, this is growing into a really interesting discussion indeed. We've identified several very different kinds of bloat, and I think that the best we can do for now is try to list them and think about ways to deal with them. I've tried to capture what we've discussed so far on the Wiki [1] <http://wiki.eclipse.org/E4/Pervasive_Themes#Reducing_Bloat> , feel free to edit!
For some kinds of bloat, there is clearly a design decision to make between forces pulling in different directions (like promoting to API vs. keeping internal; or push-into-framework vs. pull-into-optional-extension). One interesting thought here is, if we make it possible to mix-and-match an Eclipse based product on a finer granularity than today (e.g.: Take the Faceted Project Framework from WTP, but not all the rest of WTP), it might also help to reduce some unnecessary duplication. P2 might help getting the Installable Units more fine granular. I tend to agree with Kevin that likely the most important place for reducing bloat is in unnecessary duplications of API. Coming up with a single recommended way of doing things will make it easier to code against Eclipse, and free our minds from remembering duplicate ways of doing things. We may need to keep backward compatibility layers around for a while, but if "the recommended way" of doing things is attractive, I'd hope that people will jump on that way soon. One might call this "psychological problem", I'd probably rather call it "understanding, adoption, correctness and maintenance problem" as opposed to the performance issues. The other (performance) aspect of things is also interesting, but can probably be addressed later in the game. [1] http://wiki.eclipse.org/E4/Pervasive_Themes#Reducing_Bloat Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Markus Kohler Sent: Thursday, October 16, 2008 12:13 PM To: E4 developer list Subject: Re: [eclipse-incubator-e4-dev] Avoiding Bloat Hi James, On older JVM's (SUN<1.4 as far as I remember) String.intern was relatively slow. I did some tests some time ago and using a HashMap would be faster! You may want some fallback in case your JVM has a poor String.intern implementation. This kind of code duplication can IMHO only be avoided, in case you have a strict policy in place. Someone would need to constantly monitor the Eclipse project for code duplication, and maybe also check for code duplicates during code reviews. Anyway I wonder whether code bloat is really the problem with Eclipse. Do we have numbers about how much code is loaded and how much memory it consumes? Or is it "only" a psychological problem? How does it compare with the actually memory allocated for objects? I would guess if the goal is that we want to scale in a multiuser enviroment, then I would guess that this is more important. Regards, Markus On Thu, Oct 16, 2008 at 11:42 AM, James Blackburn <[EMAIL PROTECTED]> wrote: On Wed, Oct 15, 2008 at 3:08 PM, <[EMAIL PROTECTED]> wrote: > > I think something similar already exists in the platform but is internal. > I'm not sure how stable/useful it is but Ctrl+Shift+T for "StringPool". Your ctrl-shift-T is a good illustration of 'code bloat' ;) For me that brings up: org.eclipse.core.internal.jobs.StringPool org.eclipse.core.internal.preferences.StringPool org.eclipse.core.internal.utils.StringPool All of which are identical. Eclipse then has a org.eclipse.core.internal.utils.StringPoolJob which calls 'shareStrings(StringPool)' on participating IStringPoolParticipants. Given that StringPool.add() uses a HashMap to reimplement String.intern() I wonder what the performance difference is between StringPool and String.intern()... James _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
