lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Miller <chris.mil...@kbcfp.com>
Subject Re: [jira] Commented: (LUCENE-1607) String.intern() faster alternative
Date Sun, 19 Apr 2009 19:16:31 GMT
As far as I can see, both these implementations only suffer from threadsafety 
problems in that they don't guarantee visibility across threads, ie it's 
possible for threads to see stale data. I don't see any prospect of corruption 
or race conditions due to out-of-order execution. So the code should work 
fine if you can live with the consequences of stale data - in this case, 
the (remote) possibility of large performance differences between VMs. Personally 
I tend to avoid such fragile and hard to maintain code unless there's a very 
good reason for it.

How about benchmarking with eg a ConcurrentHashMap instead?


> [
> https://issues.apache.org/jira/browse/LUCENE-1607?page=com.atlassian.j
> ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=127
> 00600#action_12700600 ]
> 
> 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: 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.
>> 




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