lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <>
Subject [jira] Commented: (LUCENE-1607) String.intern() faster alternative
Date Sun, 19 Apr 2009 18:55:47 GMT


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