lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: FieldCacheImpl mistake?
Date Wed, 14 Feb 2007 20:18:41 GMT
Here is the comment:

     * Note that this method signature avoids having a user call new
     * o.a.l.d.Field(...) which would be much too expensive due to the
     * String.intern() usage of that class.
     * More often than not, String.intern() leads to serious performance
     * degradations rather than improvements! If you're curious why, check
     * out the JDK's native code, see how it oscillates multiple times back
     * and forth between Java code and native code on each intern() call,
     * only to end up using a plain vanilla java.util.HashMap on the Java
     * heap for it's interned strings! String.equals() has a small cost
     * compared to String.intern(), trust me. Application level interning
     * (e.g. a HashMap per Directory/Index) typically leads to better
     * solutions than frequent hidden low-level calls to String.intern().
     * Perhaps with some luck, Lucene's (and and
     * cousins could be fixed to not use String.intern(). Sigh :-(

karl wettin wrote:
> 14 feb 2007 kl. 20.49 skrev Mark Miller:
>> There is some code in contrib with comments claiming this interning 
>> is actually slower. I think it was the MemoryIndex? Has this ever 
>> been discussed?
> There is of course a cost of RAM and CPU involved with flyweighting 
> instances. In order to win the CPU costs back you need to do compare 
> an instance to something else more than once. Thats pretty much it, I 
> think. There might also be some weak/soft/whatnot reference costs 
> involving values passed to String.intern, but I'm not sure.
> --karl
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message