Re: ResourceBundle optimisation

[Nicolas Geoffray]

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.

> Regards
>
> Bryce
Nicolas