[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ResourceBundle optimisation

From: Nicolas Geoffray
Subject: Re: ResourceBundle optimisation
Date: Thu, 07 Jul 2005 10:33:50 +0200
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050509)

Hi Bryce,

Bryce McKinlay wrote:

Nicolas Geoffray wrote:

My mistake, i gave you a patch against classpath-0.13. Here's a patch against the latest cvs.

Nicolas Geoffray wrote:

Hi everyone,

I've been doing benchmarks beween my vm and another one launching Tomcat and noticed that the startup spent a long time trying to find Resouces with getBundle. The thing is, ResourceBundle uses a cache for the resources it founds, but i think it's not perfectly used.

When getBundle is entered, it first tries to find the resource in the cache. If it's not found, it calls tryBundle. Then tryBundle tries to load ressources with different locales, but never searches in the cache, allthough it could.

I made a patch for it and gained 2 minutes during startup of tomcat (using an ibook 500Mhz). It's attached.

Hi Nicolas,

I don't think this patch is correct. If an application requests the same bundle baseName, but with a different locale, the locale argument will be ignored and the first bundle placed in the cache will be returned.

No, because in tryBundle, a new string is created with basename + locale. It is that new string that is put in the cache, not just the basename. For example, say you're looking for a resource "MyResource" with locale en_US. If it is found, then the result is cached with a key created from MyResource_en_US, not MyResource.

Never the less, I'd be interested to know where the 2 minute speedup came from, and if there is anything we can do to improve ResourceBundle without breaking its semantics. Does Tomcat request the same bundle baseName for many different locales?

It is when it loads struts. It is looking for a resource ApplicationProperties with all the locales classpath has. With the current implementation of ResourceBundle, looking for all resources takes a real long time. Here's an example : 1) You're in getBundle looking for resource ApplicationProperties with locale AA_aa
2) It's not in the cache, so you go into tryBundle
3) In tryBundle, you don't find ApplicationProperties_AA_aa
4) In tryBundle you find ApplicationProperties_AA so you return it
5) In getBundle you cache ApplicationProperties_AA_aa with the result (ApplicationProperties_AA is not cached) 6) In the next getBundle, you're looking for ApplicationProperties with locale AA...

The patch improves the researches by caching ApplicationProperties_AA.

Even better, in tryBundle when a result is found for a resource, we could cache all intermediary resources we were looking for. For example if we were looking for ApplicationProperties_AA_aa, and finally found a result for ApplicationProperties (with no locale), we could cache ApplicationProperties, ApplicationProperties_AA_aa, and ApplicationProperties_AA with that same result.

I haven't done this greater optimisation, as i'm not sure of the correctness of the patch regarding "the most specialized bundle" in tryBundle.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]