Re: java.util.Date.toString() really slow?

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

Jeff Sturm wrote:

> On 4 Jun 2002, Tom Tromey wrote:
>  
>
> > Bryce> Presumably it would be reasonable to cache negative results for
> > Bryce> resource bundle (and class?) lookups. People don't expect to be
> > Bryce> able to dynamically add new resource bundles to a running
> > Bryce> application, right?
> >
> > I wonder.  Maybe someone could test the JDK and see what it does.  You
> > could imagine wanting to dynamically add resource bundles to some
> > long-running application like a web server -- it isn't a completely
> > absurd idea.
> >    
> My thoughts:
>
> - Dynamically replacing locale data or other system bundles isn't likely
> to happen, so Per's suggestion of caching the default locale bundle is a
> good idea.
ResouceBundles should definately be cached - I'm pretty sure we do it 
and the spec suggests this behaviour:

"Implementations of |getBundle| may cache instantiated resource bundles 
and return the same resource bundle instance multiple times."

What we don't do is cache the fact that a certain resource bundle 
_doesn't_ exist. I agree that Per's suggestion of caching the default 
locale bundle is ok, but its a bit of a peephole optimization. I'd 
prefer to optimize ResourceBundle and the default class loader so that 
it is fast in all cases.

For libgcj the overhead of a failed attempt to load a class or resource 
is particularly large because of the way dlopen() attempts to load 
several different .so files for each class. Perhaps we should cache 
negative dlopen() results as well.


> So the decision to cache the resource might best be left with the
> classloader, and the system classloader might as well cache its results
> forever.  (Mine's a pragmatic view not necessarily based on fact, but on
> real experience with sometimes ill-behaved web applications.)
>  
I agree and I suspect that this is the way things work in the JDK. I'll 
try to confirm this before we start hacking it, though.

regards

Bryce.