lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Earwin Burrfoot (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1607) String.intern() faster alternative
Date Sun, 19 Apr 2009 19:11:47 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700601#action_12700601
] 

Earwin Burrfoot commented on LUCENE-1607:
-----------------------------------------

bq. This default would be more back compatible since programs may rely on String instances
being interned via String.intern(). 
My version is also String.intern()-compatible

bq. Earwin, I took a quick look at your implementation just now, but it doesn't look thread-safe.
unlock for one thread happens-before lock on the same monitor for the other thread, inside
each thread each action happens-before the next one
Since I get pool reference for the second time after the lock, and write pool reference before
unlocking, everything's fine. As for the other threads, if they find what they need in the
pool, it doesn't matter if they're seeing a stale pool, or not. If they don't find what they
need, they hit the lock, re-retrieve pool reference, getting the latest one and either find
what they need there, or write.
Correct me if I'm wrong?

bq. though I did wonder about the cost of making the new hashmap every add
It's COSTLY :) But you're going to pay all of it at startup.

I think we can introduce the class (without any interfaces, why should we need one here?),
and then try to make it faster by switching storage. I tried GNU Trove THashMap, but on Java
6 it was slower than stock HashMap.

> 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
>
>
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message