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