[
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718198#action_12718198
]
Earwin Burrfoot commented on LUCENE-1607:
-----------------------------------------
bq. but I was waiting for some kind of feedback if people in general thought it
was the right approach. It introduces another static, and people tend to not
like that.
Just forgot somehow about this issue.
You're right about static, it's not clear how and when to initialize it, plus
you introduce some public classes we'll be unable to change/remove later.
I still have a feeling we should expose a single static method - intern() and
hide implementation away, possibly tuning it to be advantageous for <thousands
of fields, and degrading to raw String.intern() level if there are more fields.
I'm going to be away from AC power for three days starting now, so I won't be
able to reply until then.
> 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, 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
