RE: [eclipse-incubator-e4-dev] Avoiding Bloat
this is growing into a really interesting discussion
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
about ways to deal with them. I've tried to capture what
discussed so far on the Wiki
, 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
mix-and-match an Eclipse based product on a finer
than today (e.g.: Take the Faceted Project Framework
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.
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
but if "the recommended way" of doing things
attractive, I'd hope that people will jump on that way
One might call this
"psychological problem", I'd probably
rather call it "understanding,
adoption, correctness and
maintenance problem" as opposed
to the performance issues.
(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
On older JVM's (SUN<1.4 as far as I remember) String.intern was
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
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
Anyway I wonder whether code bloat is really the problem with
Do we have numbers about how much code is loaded and how much memory it
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>
Your ctrl-shift-T is a good
illustration of 'code bloat' ;)
On Wed, Oct 15, 2008 at 3:08 PM, <Mark_Melvin@xxxxxxxx
> 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".
For me that brings
of which are identical.
Eclipse then has a
'shareStrings(StringPool)' on participating
Given that StringPool.add() uses a HashMap
String.intern() I wonder what the performance
difference is between
StringPool and String.intern()...