[
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704306#action_12704306
]
Yonik Seeley edited comment on LUCENE-1607 at 4/29/09 1:23 PM:
---------------------------------------------------------------
The last patch removed the ability to plug a different implementation, but I
guess we don't need that until we have another implementation (and it's not
clear if the benefits of dumping String.intern() compatability in the future
outweigh the disadvantages of breaking back compatibility).
Rethinking what possible problems this could have... I'm not sure it should be
committed in it's current form. One problem is potentially unlimited growth
where there was not before. This could happen in a long running search system
where users enter a variety of field names that don't even exist.
A WeakReference based approach would work (as String.intern() uses), but that's
more heavyweight and could need synchronization since we are dealing with more
complex objects.
Another option is to go back to a simple cache based approach which could still
pin otherwise unreferenced Strings in memory, but would have a bounded size.
Perhaps this argues for reinstating the pluggability of the intern
implementation.
was (Author: ysee...@gmail.com):
The last patch removed the ability to plug a different implementation, but
I guess we don't need that until we have another implementation (and it's not
clear if the benefits of dumping String.intern() compatability in the future
outweigh the disadvantages of breaking back compatibility).
I plan on committing this shortly.
> String.intern() faster alternative
> ----------------------------------
>
> Key: LUCENE-1607
> URL: https://issues.apache.org/jira/browse/LUCENE-1607
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Earwin Burrfoot
> Fix For: 2.9
>
> Attachments: intern.patch, LUCENE-1607.patch, LUCENE-1607.patch,
> LUCENE-1607.patch, LUCENE-1607.patch, LUCENE-1607.patch
>
>
> By using our own interned string pool on top of default, String.intern() can
> be greatly optimized.
> On my setup (java 6) this alternative runs ~15.8x faster for already interned
> strings, and ~2.2x faster for 'new String(interned)'
> For java 5 and 4 speedup is lower, but still considerable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
