lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <>
Subject [jira] Commented: (LUCENE-1607) String.intern() faster alternative
Date Mon, 20 Apr 2009 21:02:47 GMT


Yonik Seeley commented on LUCENE-1607:

bq. The fastest hash we can get, should have no collisions. This is achievable by resizing
on each new collision.

Hmmm, in my quick'n'dirty tests of about 256 unique strings, a smaller hash table was actually
quicker (initialized with 32 and let it resize vs starting at 1024).  I imagine that this
would be due to a larger part of the table fitting in smaller and faster processor caches.
 YMMV.  Collisions should also be very quick to skip by comparing the hash code (which is
cached for Strings).

> String.intern() faster alternative
> ----------------------------------
>                 Key: LUCENE-1607
>                 URL:
>             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,
> By using our own interned string pool on top of default, String.intern() can be greatly
> 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:
For additional commands, e-mail:

View raw message