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


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:

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()...

eclipse-incubator-e4-dev mailing list

Back to the top