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


Hi Martin,

Some great points.

The kind of bloat I'd like to trim is the overly complex frameworks.  This is probably the hardest to cut down though because of API considerations.  I suspect that the most egregious cases have grown out of a simple initial model, with overtime new requirements added, so that its kind of grown lopsided and out of proportions.  Add a kitchen here, a sunroom there, a new garage... and now you have to go through the basement to have breakfast.  Our big advantage today is that presumably we understand how Eclipse is being used (vs. 10 years ago when we'd hope for cleverness and luck).  So I'd love to see some simplifying frameworks that still capture a broad usage.  Getting things like singletones is a good step.  

But this is all speaking very generally.  The hope is that there are some common simplifying patterns we can apply, but I fear that the reality is that each case will need to be examined invidiually.

I don't mind the platform being big if its because its including common pieces that avoid downstream plugins/products from having to duplicate.  Its its purpose, provided of course that the likelyhood of reuse is high enough to warrant everyone getting it.  Optional packages/plugins are one option but I think the packagings have gotten sufficiently large and complex that its hard to know what you can exclude, as anyone who has tried to build an RCP app which uses IResources can attest to.

Wrt the string and image discussion, you're right, I misunderstood :)

Regards,

Kevin



"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

10/15/2008 05:33 PM

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

To
"E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc
Subject
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...
 
[1] http://winstone.sourceforge.net/#whatIs
[2] http://retroweaver.sourceforge.net/
[3] http://www.eclipse.org/aspectj/
 
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 


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.


Regards,

Kevin




Mark_Melvin@xxxxxxxx
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>


To
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc
Subject
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".


Mark.
----------------------------------------------------------


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>


To
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc
Subject
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:
http://forums.sun.com/thread.jspa?threadID=741223

Boris
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev

_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev


Back to the top