classpath
[Top][All Lists]
Advanced

[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





reply via email to

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