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 Field.java (and Term.java) 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
