Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <1396336863.1241036670424.JavaMail.jira@brutus>
Date: Wed, 29 Apr 2009 13:24:30 -0700 (PDT)
From: "Yonik Seeley (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Issue Comment Edited: (LUCENE-1607) String.intern() faster
 alternative
In-Reply-To: <471081983.1240154567606.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Yonik Seeley edited comment on LUCENE-1607 at 4/29/09 1:23 PM:
---------------------------------------------------------------

The last patch removed the ability to plug a different implementation, but I guess we don't need that until we have another implementation (and it's not clear if the benefits of dumping String.intern() compatability in the future outweigh the disadvantages of breaking back compatibility).

Rethinking what possible problems this could have... I'm not sure it should be committed in it's current form.  One problem is potentially unlimited growth where there was not before.  This could happen in a long running search system where users enter a variety of field names that don't even exist.

A WeakReference based approach would work (as String.intern() uses), but that's more heavyweight and could need synchronization since we are dealing with more complex objects.
Another option is to go back to a simple cache based approach which could still pin otherwise unreferenced Strings in memory, but would have a bounded size.  Perhaps this argues for reinstating the pluggability of the intern implementation.


      was (Author: yseeley@gmail.com):
    The last patch removed the ability to plug a different implementation, but I guess we don't need that until we have another implementation (and it's not clear if the benefits of dumping String.intern() compatability in the future outweigh the disadvantages of breaking back compatibility).

I plan on committing this shortly.
  
> 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, LUCENE-1607.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 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