Re: [platform-core-dev] New platform NLS support

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

The document in my original email on
this subject outlined the rationale and performance gains.  Essentially,
the property file based approach has the following in memory for each message
in your catalog:

- The constant string in your code where
the key is referenced.  This is generally stored in the VM as a UTF
string.
- When the constant is referenced, a
java.lang.String object is created for the constant (44 bytes  for
the String and char[] objects plus two bytes per character).  
- The loaded property file is stored
in a Hashtable, which has another String object for the key (equal but
not identical), and a String object for the message value.
- A HashtableEntry object (typically
about 24 bytes).  

The memory cost for *each* key is 112
+ 5N, where N is the number of characters in the key.  The new format
just has the Java field name stored as a UTF string (size N),  Thus
a message key with ten characters used 162 bytes of memory space with the
properties file, versus 10 bytes for the new approach (ignoring the benefit
of getting rid of the Hashtable.Entry[] and Hashtable objects).  Multiply
this savings in a product with thousands of messages and this amounts to
a significant savings.

Any ResourceBundle approach requires
String objects as keys.  ListResourceBundle also uses a Hashtable
with String keys so it's comparable to PropertyResourceBundle.

Mazen Faraj/Toronto/IBM@IBMCA
Sent by: platform-core-dev-admin@xxxxxxxxxxx

23/02/2005 03:36 PM

Please respond to
platform-core-dev

To	platform-core-dev@xxxxxxxxxxx
cc
Subject	Re: [platform-core-dev] New platform NLS support

John, 
is there a document that explains what the issue was with using ResourceBundles
like we did today? what part of that class design was the memory drainer?
And just out of curiosity, why didnt you do a custom java.util.ResourceBundle?
meaning implement ListResourceBundle or ResourceBundle and the implementation
can still prime fields (just like in the current proposal).? Rationale:
using a JDK class is familiar territory, and you may still be able  to
bypass today's overhead. 

Mazen.

John Arthorne/Ottawa/IBM@IBMCA
Sent by: platform-core-dev-admin@xxxxxxxxxxx

02/23/2005 01:49 PM

Please respond to
platform-core-dev

To	platform-core-dev@xxxxxxxxxxx
cc
Subject	Re: [platform-core-dev] New platform NLS support

That's a bit tricky because you would then have multiple classes with the
same name, loadable by the same class loader.  Special magic in the
platform class loaders would probably be needed.  It's certainly possible
with the new scheme to assign the field ahead of time and avoid the initialization
that currently happens on load - for example if you were already shipping
different versions of your product for each language. I think a major value
of plug-ins using an Eclipse NLS API, is that if we come up with further
optimizations later on, they can be applied to the immediate benefit of
all with little further effort. 

Also keep in mind that if you have no attachment to the .properties file
format, java.util.ResourceBundle allows you to use a pure class-based system
that does a language-specific class lookup to load the bundle, as you suggest.
 The Eclipse API is a middle ground that has very good runtime memory
characteristics but still retains the .properties file format that is familiar
and often favoured by translators. 


Bob Foster wrote on 23/02/2005 01:12:08 PM:

> Did you consider allowing the message class to be loaded dynamically
at 
> startup, like fragment classes? This would require that translators
run 
> the tool and compile a class per properties file, but would reduce
the 
> need for runtime interpretation to zero. (The default class, if loaded,
> would simply do what it does now.)
> 
_______________________________________________ platform-core-dev mailing
list platform-core-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/platform-core-dev