I understand. The cost of the additional IF statements in the caller of the
Collector would not outweigh the cost of throwing an Exception for these use
cases
Anne
On Wed, Sep 7, 2011 at 16:00, Simon Willnauer <
simon.willna...@googlemail.com> wrote:
> I agree we should not introduce a condition
I agree we should not introduce a condition here. this extra branch is
totally unnecessary.
simon
On Wed, Sep 7, 2011 at 3:49 PM, Uwe Schindler wrote:
> ...but slower, as you have to check the return value millions of times. For
> this type of early exit conditions, exceptions are better, as the
In that case it is better to keep the mechanism of throwing an exeption to
stop a search. I was just thinking about the collector api and how Anne's
change would look.
On 7 September 2011 15:49, Uwe Schindler wrote:
> ** ...but slower, as you have to check the return value millions of times.
> F
...but slower, as you have to check the return value millions of times. For
this type of early exit conditions, exceptions are better, as they only change
control flow if they are throwed. If you preallocate the exception, the time
for fill-in stack trace is minimized. With Java 7 throwable has
but its a per-document if for the normal case of ranked results, just
to look "pretty" ?!
On Wed, Sep 7, 2011 at 9:36 AM, Martijn v Groningen
wrote:
> I think that a boolean or enum as return value is neater (api wise) than
> throwing an expection.
>
> On 7 September 2011 15:34, Anne Veling wrot
its not slower:
http://blogs.oracle.com/jrose/entry/longjumps_considered_inexpensive
I don't understand the thing about the booleanquery.
On Wed, Sep 7, 2011 at 9:34 AM, Anne Veling wrote:
> Yes, I saw that. I would expect that to be slower. It also would not always
> work as expected if the col
I think that a boolean or enum as return value is neater (api wise) than
throwing an expection.
On 7 September 2011 15:34, Anne Veling wrote:
> Yes, I saw that. I would expect that to be slower. It also would not always
> work as expected if the collector would be combined in a booleanquery I
>
Yes, I saw that. I would expect that to be slower. It also would not always
work as expected if the collector would be combined in a booleanquery I
guess.
Anne
On Wed, Sep 7, 2011 at 15:29, Robert Muir wrote:
> On Wed, Sep 7, 2011 at 9:09 AM, Anne Veling wrote:
> > Ah thanks. I will make the c
On Wed, Sep 7, 2011 at 9:09 AM, Anne Veling wrote:
> Ah thanks. I will make the change, ensure all tests are succeeding, add some
> tests of my own, and commit a patch. Would be great to get a feeling of the
> performance impact.
> The change I'm making is changing the Collector interface from
> p
Ah thanks. I will make the change, ensure all tests are succeeding, add some
tests of my own, and commit a patch. Would be great to get a feeling of the
performance impact.
The change I'm making is changing the Collector interface from
public void collect(int doc) to
public boolean collect(int doc
This sounds like a neat patch -- what changes are you exploring to Collector?
These days when I need to test indexing or searching performance I
usually use the Python scripts from here:
https://hg.codespot.com/a/apache-extras.org/luceneutil
Unfortunately they are rather involved to set up (
I've been following the Lucene/Solr community for a long time and finally
have found (or: taken) the time to start implementing some of my ideas how
to improve on it; this will be my first proposed patch.
I'm working on some changes to the Collector API to significantly improve
the performance of
12 matches
Mail list logo
