[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: patch 620
From: |
Stephen Crawley |
Subject: |
Re: patch 620 |
Date: |
Thu, 28 Nov 2002 23:37:43 +1000 |
> On Wed, 2002-11-27 at 16:29, Tom Tromey wrote:
> > Anthony, patch 620 (you submitted it a few weeks ago) restores
> > intern()ing of Locale fields. Is this important for performance?
>
> I think so - but I don't have any proper evidence.
Intuition can be unreliable when deciding what to optimize, and whether
an optimization has been sucessuful ...
> Locales are used as
> keys a fair bit. Interning the strings makes Locale comparisons much
> faster. It just seems like a good idea, and it simplifies some of the
> code as well. I can't think of any reason why we shouldn't do this.
Here are a couple of theoretical reasons why interning (in general)
could have negative performance implications, for Kissme at least.
* I believe that Classpath's String interning uses a weak hashmap.
Unfortunately, Kissme does not support weak references yet. Instead
it treats weak references as ordinary references. This means that
Kissme cannot garbage collect any String that has been interned.
* You may be aware that the Kissme VM includes an implementation of
orthogonal persistence. In one possible configuration of Kissme
O-P, static fields of classes get automatically saved to the
persistent store. This would include String's interning data
structures. Thus interned Strings would last "for ever" in the
store.
[Arguably, the latter is the correct behaviour. If a Kissme persistent
application interns a String, the persistency transparency principle
says that saving and restoring the String shouldn't alter its computational
properties. This includes the property that the String is == to other
interned Strings with the same characters.]
Note: I'm not saying "don't intern these locale Strings". If there is
a demonstrable performance benefit, go for it.
-- Steve