[ 
https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Earwin Burrfoot updated LUCENE-1607:
------------------------------------

    Attachment: LUCENE-1607.patch

Okay, I thought more about that. Yonik is amazing.

The fastest hash we can get, should have no collisions. This is achievable by 
resizing on each new collision. Then we should introduce an upper bound for 
this process, for it not to blow up. Finally, we can use our upper bound for 
hash size from the start.

I benchmarked a bit, it works better than HashTable.
Somewhat better for already interned strings, much better for noninterned 
strings.
"s1==s2 || s1.compareTo(s2) == 0" combo amazingly works faster than 
s1.equals(s2).
Additional hashcode check makes sparse hash access a bit slower and doesn't 
really help with crowded hash.
Having a crowded hash degrades performance a lot. 

I updated my patch with Yonik's algorithm. Kept everything in statics (faster), 
allowed to change cache size through system property for adventurous types, 
default is 16k (works well for 100 values)

> 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
>
>
> 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

Reply via email to