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

[Bryce McKinlay]

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.