| Re: [eclipse-incubator-e4-dev] Avoiding Bloat |
Hi Martin,
I'm coming back to this post because tonight I did some testing on how
we could replace this statically initialized class fields used nowadays
through a more dynamic-approach where the String could come from
whatever resource we want. To make this work I think the way to go is to
use interfaces instead of these static fields.
Let me first of explain where I'm coming from because I think this
explains better why I'm doing it the way I outline here.
I need a common way for i18n in GWT and RCP-Applications. GWT is
different in here because there the compiler does all the work when you
compile the Java-Code to JavaScript creating one executeable / language.
Let me explain how GWT works:
a) One defines an custom interface which extends a marker interface
public interface MyMessages extends Localizable {
public String myString();
}
b) One creates an "dynamic" instance
MyMessages myMessages = GWT.create(MyMessages.class);
When reading the above one could think that GWT.create() is similar to
Class.forName().newInstance() but naturally it is not because MyMessages
is an interface. The developer is *not* creating a class which
implements the the interface but the GWT-compiler does this on the fly
(hence the on executeable / language).
So how could we bring all this to the world of Java. I hacked together
some test code which uses Proxy.newProxyInstance to find out big the
performance impact is going to be (Code is attached as a zip to this mail).
To test performance I implemented 4 cases:
a) Interface is backed up by a ResourceBundle
b) Interface is backed up by an NLSClass which itself implements the
Interface
c) Interface is backed up by an NLSClass which itself does not
implement the Interface
d) Traditional NLSClass (like we all use NLS in todays bundles) where
fields are access.
The test code looks like this:
> /**
> * @param args
> */
> public static void main(String[] args) throws Exception {
> Messages m = MessageFactory.create(MessagesResourceBundle.class);
>
> timeIt("Resource-Bundle: ", m,1000000);
>
> m = MessageFactory.create(MessagesNLSInterface.class);
>
> timeIt("NLS-With-Interface: " , m,1000000);
>
> m = MessageFactory.create(MessagesNLSNoInterface.class);
>
> timeIt("NLS-Without-Interface: " , m,1000000);
>
> long start = System.currentTimeMillis();
> String s;
> for( int i = 0; i < 1000000; i++ ) {
> s = MessagesTarget.simpleTest;
> }
>
> long end = System.currentTimeMillis();
> System.err.println("Traditional: " + 1000000 + " took " + (end - start) + " => " + (end - start) * 1.0 / 1000000);
> }
>
> private static void timeIt(String type, Messages m, int iterations) {
> long start = System.currentTimeMillis();
>
> String s;
> for( int i = 0; i < iterations; i++ ) {
> s = m.simpleTest();
> }
>
> long end = System.currentTimeMillis();
> System.err.println(type + ": " + iterations + " took " + (end - start) + " => " + (end - start) * 1.0 / iterations);
> }
The figures are like this:
Resource-Bundle: : 1000000 took 112 => 1.12E-4
NLS-With-Interface: : 1000000 took 8 => 8.0E-6
NLS-Without-Interface: : 1000000 took 1247 => 0.001247
Traditional: 1000000 took 3 => 3.0E-6
So for 1.000.000 calls we have a performance penalty of 5 ms.
Tom
Oberhuber, Martin schrieb:
> Boris wrote:
>
>> I have written a blog post about the bloat topic:
>> _http://borisoneclipse.blogspot.com/2008/10/avoiding-bloat.html_
> Great posting!
>
> It inspired me to think about another potential reason for bloat:
> duplication of graphics, images and NLS Strings
>
> We do have ISharedImages, but more often than not a plugin
> is forced to duplicate some image or resource String because
> the original owner of that image or String is (rightfully) hiding
> that resource and doesn't want to expose it as API.
>
> But isn't that a *development-time / installation-time restriction*
> only? Why do we need to bother the plugins at runtime with
> duplicates of the same Strings and images getting loaded
> into Memory, in multiple ImageRegistries etc... I'd not be
> surprised if we could get rid of a good deal of the "*Running out*
> *of PermGen Space*" issue with a different approach to loading
> Images and Strings at runtime.
>
> 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.
>
> I think we should work on the Wiki pages, adding additional
> ideas for reducing Bloat as we find them. I'm just struggling
> to find time for that...
>
> Cheers,
> --
> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River*
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
--
B e s t S o l u t i o n . a t EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl leiter softwareentwicklung/CSO
------------------------------------------------------------------------
eduard-bodem-gasse 8/3 A-6020 innsbruck phone ++43 512 935834
Attachment:
testi18n.zip
Description: Zip compressed data