[
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700600#action_12700600
]
Mark Miller commented on LUCENE-1607:
-------------------------------------
bq. Earwin, I took a quick look at your implementation just now, but it doesn't
look thread-safe.
That was my first impression too, but I couldnt pin down the issue. The access
will either be against the old pool, or it will be against the new pool, and
the instance switch should be atomic? I figured it was a clever trick of some
kind (though I did wonder about the cost of making the new hashmap every add).
The HashMaps are read only right (once they can be accessed by multiple
threads)? And they are popped in with an atomic variable assignment?
> 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
>
>
> 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
