Return-Path: Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: (qmail 4926 invoked from network); 25 Feb 2011 12:28:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 25 Feb 2011 12:28:38 -0000 Received: (qmail 16363 invoked by uid 500); 25 Feb 2011 12:28:37 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 15877 invoked by uid 500); 25 Feb 2011 12:28:35 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 15855 invoked by uid 99); 25 Feb 2011 12:28:35 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Feb 2011 12:28:35 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [130.225.24.68] (HELO sbexch03.sb.statsbiblioteket.dk) (130.225.24.68) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Feb 2011 12:28:26 +0000 Received: from [130.225.25.23] (130.225.25.23) by sbexch03.sb.statsbiblioteket.dk (130.225.24.68) with Microsoft SMTP Server id 8.3.137.0; Fri, 25 Feb 2011 13:28:05 +0100 Subject: Re: Proper use of TermsEnum.seek? From: Toke Eskildsen Reply-To: te@statsbiblioteket.dk To: dev@lucene.apache.org CC: simon.willnauer@gmail.com In-Reply-To: References: <1298298452.15099.84.camel@te-prime> <1298372149.15099.143.camel@te-prime> Content-Type: text/plain; charset="UTF-8" Organization: State and University Library, Denmark Date: Fri, 25 Feb 2011 13:28:05 +0100 Message-ID: <1298636885.12733.14.camel@te-prime> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Tue, 2011-02-22 at 12:19 +0100, Simon Willnauer wrote: [Toke: Using a partial cache of BytesRef+TermState] > I don't know how you did implement that part but you might consider > using something like ByteBlockPool instead of BytesRef instances to > safe an extra amount of memory. Just as a hint you can look at > BytesRefHash for an example. Avoiding the overhead of representing the BytesRefs as separate Objects seems sensible. Unfortunately this isn't possible with TermState, at least not in general. As I focus quite a bit on memory overhead, tt might make sense to just store the BytesRef and take the performance penalty of seek(BytesRef) to avoid the Object-overhead of TermStats. > I think we need to check if that BytesRef is really needed. I hope we > can get rid of it eventually. It does seem a bit peculiar that is is needed for a seek using a previously delivered marker. Maybe the TermState could hold a reference to the BytesRef itself, if it is needed by the implementation? Regards, Toke Eskildsen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional commands, e-mail: dev-help@lucene.apache.org