Re: [eclipse-incubator-e4-dev] Avoiding Bloat

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

I agree code bloat is a big problem,
and it gets worse every year (Eclipse SDK size is 37MB/55MB/87MB/155MB
in 1.0/2.0/3.0/3.4 respectively). More importantly for this stage in e4,
it's not something that's easily optimized later, unlike strings and images.
Here are some thoughts on ways to reduce code bloat:

 - Be more cautious about introducing
API. We have lots of bloat from releasing multiple attempts at a given
API, which we then need to support forever and can never remove. The common
pattern is that we introduce API in release N. Clients only start heavily
adopting the API after release N, and this feedback often results in API
changes being needed in release N+1 (rinse, repeat). In more recent releases
we have become more aggressive at pulling back API that wasn't ready or
didn't have sufficient client feedback, to avoid having to indefinitely
support API mistakes and limitations. I'd like to see this happen in e4
too. Go wild early on in the development cycle and add what you want, but
as the release approaches, only "graduate" API that is proven.
I would even advocate some kind of review by project leads for any significant
new API, where the API designer has to demonstrate that the API is platform
quality, is thoroughly documented, and has multiple clients using it before
it gets approved for release as real API.

- Do regular code weeding. As code is
developed, there always accumulates dead code, images, and other resources
that were used for awhile and then no longer used. We should use coverage
analysis and other tools to root out and remove unused code/images/strings
on a regular basis. This often happens when classes are copied and the
new user only uses a subset of the copied functionality.

- Cap and trade. This might be a bit
over the top, but I have wondered about having a quota on plug-in or component
sizes such that they can only grow by so much in a given release. Extra
growth can be compensated by making reductions elsewhere. I don't expect
this idea to be too popular, but what I'm looking for here is some incentive
for developers to avoid bloat. Often there is very little incentive for
a developer to avoid bloat, and in a crunch it's too easy to copy wads
of code from other plug-ins to get the job done. Or, a large third party
library will be added because using some small portion of it will save
a bit of work. Code hygiene work such as the weeding mentioned above are
also the first things to get dropped when people become busy. It seems
without a concrete motivation to avoid bloat, it will inevitably occur.

John

Kevin McGuire/Ottawa/IBM@IBMCA
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

10/15/2008 10:45 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

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