[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [eclipse-incubator-e4-dev] Avoiding Bloat
|
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], 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.
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
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
<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:
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