Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <786fde50906220025u6756b56cnf56a4b48b403e345@mail.gmail.com>
References: <BLU142-W9E2ECC201376A6F96AAB7C6380@phx.gbl>
	 <786fde50906220025u6756b56cnf56a4b48b403e345@mail.gmail.com>
Date: Mon, 22 Jun 2009 05:29:25 -0400
Message-ID: <9ac0c6aa0906220229t1f9b0d26n53c154f719cc727d@mail.gmail.com>
Subject: Re: Optimization of memory usage in PriorityQueue
From: Michael McCandless <lucene@mikemccandless.com>
To: java-dev@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Mon, Jun 22, 2009 at 3:25 AM, Shai Erera<serera@gmail.com> wrote:

> Or ... we can do nothing, and say that one can write his own Collector, and
> use Sun's PQ (or any other), if one has a case like "I need 10K results, but
> I don't know how many are there, and specifically I want to optimize for the
> case of 1 result".

+1

I think Lucene's current PQ is optimized for the [very] common case,
and if someone would like to eg swap to Sun's PQ impl, the custom
Collector API is the best route.  (And, I'd love to hear back on how
the performance compares!  If Sun has a faster PQ than Lucene, we
should fix that ;) ).

Though, are Lucene's core collectors reusable?  If you did really want
say 100K results out of each search (very unusual), it'd be nice to
not have to throw away the Collector/PQ each time.

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org