lucene-dev mailing list archives

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


Earwin Burrfoot commented on LUCENE-1607:

Okay, you're probably right. It's not that hashmap can be corrupted on subsequent write, it's
that reader threads can possibly see not-yet-built hashmap.
And volatile works, while simple sync doesn't, because volatile also orders reads. 
Hm. Hm. Hm.
Than, as you suggested, all we need is our own hash implementation that remains usable even
being partially updated. I skipped through your patch and something looks suspicious to me.
Like lack of collision resolve and that line:
int slot = h & (cache.length-1);
It'll break on non-power-of-two sizes.

> 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