[
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704313#action_12704313
]
Earwin Burrfoot commented on LUCENE-1607:
-----------------------------------------
Is there 'any' benefit of dumping String.intern() compatibility? All those
interns happen at startup anyway.
If future brings us something better (which I doubt in this case), we'll just
swap the impl, which is all-private.
All in all I consider a practice of system-property-driven pluggable
implementations a sickening one. Take MMapDirectory that was impossible to use
until now without twiddling with startup keys, take
SegmentReader/ReadonlySegmentReader - resulting code is ugly and nobody's going
to override defaults anyway, all important dependencies are package-private.
> 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
