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

Thanks Kevin.
I fully agree that reducing the code bloat is likely the most interesting
area. Looking at Winstone [1], "servlet functionality without the bloat
that full J2EE compliance introduces", I got the idea that reducing
code bloat is likely related to getting rid of less-often-needed functionality.
Which is interesting in the context of a component platform like Eclipse.
Where does the bloat start? Is Equinox bloated? Likely not, though there
exist commercial embedded OSGi implementations like which I think are
smaller. Is the core Platform bloated? The Eclipse SDK? The Modeling
Package? Ganymede? Galileo?
Given that a component platform is made to mix-and match components,
it's getting harder and harder to avoid bloat / duplication the more the
components are separate from each other. There needs to be constant
communication and interaction between the core framework and all
adopters in order to reduce bloat. One way of reducing bloat
in the large application, is pushing functionality down into the core
framework (which might, incidentally, be perceived as making the
framework bloated).
On the other hand, reducing bloat in the Framework is possible
by factoring out functionality into optional modules (which are not
always necessarily loaded).
But I'm getting too philosophical. To me, the key for avoiding code
bloat is providing small but powerful abstractions and programming
models in the core framework. And the constant reaching out to the
community to actually use the new, modern, flexible frameworks
instead of the older style ones... thinking of modern flexible Eclipse
core.expressions here, along with Commands and ui.menus, versus
the older action framework for instance.
Without doubt, e4 with all the e3 compatibility layers will be bloated.
What are we going to do to make the e4 core slick, such that people
WANT to use the new mechanisms?
Strings and Images
You probably mis-read me. In my model, images and Strings are
not shared at development / install time and are thus not API.
But when a bundle gets installed, all those resources are thrown
into a common database such that they can be shared at runtime,
and they don't need to remain in memory all the time.
I'm assuming that from all the NLS Bundles we have in a running
Eclipse instance today, typically not more than 20% are ever needed
at runtime (and the rest are error messages which are displayed
very rarely). Yet their NLS classes are loaded into memory, so the
Strings are also loaded - without ever being referenced. Using a
database could allow keeping these Strings and images on disk
until they are actually needed.
I'm not exactly sure what magic technology could be used at
install time in order to turn the NLS references we have at
compile-time today into database-references at runtime. But
it's an interesting thought. And, as a matter of fact there exist
classfile rewriters such as RetroWeaver [2] and runtime code
weavers such as AspectJ [3], so perhaps it's somehow possible?
At least it should be possible if we came up with a different
mechanism for referencing externalized resources...
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 Kevin McGuire
Sent: Wednesday, October 15, 2008 4:46 PM
To: E4 developer list
Subject: Re: [eclipse-incubator-e4-dev] Avoiding Bloat

This is a good discussion.  Stepping back, I'm seeing three broad topics:

1: Strings
(well discussed already)

2: Images
Sharing an image makes it API.  Thus there is always a "do we want to keep this around forever" discussion.  Also, we'd like to remain free to change the contents of the image but there's concern about images re-used in a different/unknown context and whether the change could be bad for the consumer.  That said, I think the tendency has been to open up more and more images, with the idea being that they're likely to stick around anyway so we might as well share them.  It doesn't address the content change issue though.

3: Code
Reducing code bloat has both a positive impact on the size of the SDK (as do the above) but to me, more importantly, a positive impact on the required brain size to program Eclipse.  And a positve impact on the maintenance cost, both of the SDK and the downstream plugins.  I've always believed that code breeds more code.  I was wondering if folks on this thread had specific ideas on simplifying our code weight.

That said, I suppose strings and images are an easier place to start.



Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

10/15/2008 10:08 AM

Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>

E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
Re: [eclipse-incubator-e4-dev] Avoiding Bloat

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".


Boris Bokowski <Boris_Bokowski@xxxxxxxxxx>
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

10/15/2008 09:51 AM

Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>

E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
Re: [eclipse-incubator-e4-dev] Avoiding Bloat

Eric Moffatt wrote on 10/15/2008 09:36:56 AM:
> As far as Strings go Wikipedia indicates that java already does some
> form of this through a technique called 'interning', why should we
> try to compete?

Because there is never an easy answer ;-) ... interned strings use that especially precious "perm space" memory on some VMs. See for example:

eclipse-incubator-e4-dev mailing list

eclipse-incubator-e4-dev mailing list

Back to the top