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

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

+1  for using the existing ResourceManager
for SWT resources; it's mature code that has worked well for us.

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? A quick google lead to some suprising (to
me) optimizations such as using substrings of existing interned strings
to represent others...

Onwards,
Eric

Boris Bokowski/Ottawa/IBM@IBMCA
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

10/14/2008 05:13 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

> I'm thinking about a SINGLE ImageRegistry / StringRegistry
> (could also be a database), from which plugins can acquire 
> an image/String by means of a Key (that could be an int 
> number, for instance). At the time a bundle is installed, all
> its images / Strings are placed into the common Database.
> Clients get a Key in return, which they can use at runtime
> to retrieve their data. Identical data is collapsed.
>  
> Sounds interesting? Or am I missing something? Uninstalling
> a bundle would certainly not be easy, and I guess that the
> String and Image database would likely be an add-only thing
> to avoid lifecycle issues.

We have had great success in the past with JFace's LocalResourceManager.
As long as the keys are not taking up more space than what you save through
collapsing the real data, it sounds like a good idea.

LocalResourceManager is an object whose lifecycle is managed by its owner
(usually some plugin), so lifecycle issues are not that problematic.  Each
resource manager has a parent resource manager, but all resources (in the
JFace case: Images, Colors, Fonts) are managed at the root resource manager,
and reference-counted there.  By disposing your LocalResourceManager,
the reference counts for all resources you contributed get decremented
automatically. This also avoids the Singleton pattern... your all-caps
SINGLE made me extremely nervous. ;-)

Not sure how you would use something like this for strings though.  Given
a list of potentially not unique string objects, you can use a hash to
uniquefy them, but it's computationally expensive if done synchronously
and eagerly. (The resources plugin will uniquefy all strings used for markers,
but it's done in a background job:https://bugs.eclipse.org/bugs/show_bug.cgi?id=244631#c9)

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