Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [eclipse-incubator-e4-dev] Avoiding Bloat

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], 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.
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.
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member

From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] 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. 


On Thu, Oct 16, 2008 at 11:42 AM, James Blackburn <jamesblackburn@xxxxxxxxx> wrote:
On Wed, Oct 15, 2008 at 3:08 PM,  <Mark_Melvin@xxxxxxxx> 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:

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()...

eclipse-incubator-e4-dev mailing list

Back to the top