You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Anne Veling <an...@beyondtrees.com> on 2011/09/07 09:35:06 UTC
How to best test possible performance impact of a new lucene patch
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 some use cases, but my change may have a negative effect
on other use cases (though I doubt it), including memory resources. Of
course such an effect would only be measurable for larger index sizes.
My question is: how can I best test this? Is there a common dataset/index
that is used to verify that patches do not degrade search performance? I can
do some testing on my own wikipedia index of course, but I guess that
aligning with the performance tools you guys are using, will be better
Thank you, keep up the good work,
Anne
--
Anne Veling
BeyondTrees.com
+31 6 50 969 170
@anneveling
Re: How to best test possible performance impact of a new lucene patch
Posted by Robert Muir <rc...@gmail.com>.
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
<ma...@gmail.com> 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 <an...@beyondtrees.com> 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 guess.
>> Anne n
>>
>> On Wed, Sep 7, 2011 at 15:29, Robert Muir <rc...@gmail.com> wrote:
>>>
>>> On Wed, Sep 7, 2011 at 9:09 AM, Anne Veling <an...@beyondtrees.com> 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
>>> > public void collect(int doc) to
>>> > public boolean collect(int doc)
>>> > With a default "false" return code. If a collector returns "true" the
>>> > caller
>>> > may stop collecting. So all normal collectors would simply return
>>> > "false".
>>> > This could introduce some performance overhead of adding a return value
>>> > to
>>> > the call stack, and some checking in the calling code.
>>> > However, for some other use cases, like
>>> >
>>>
>>> usually the trick here to stop collecting is to throw a
>>> runtimeexception (your own subclass that you can catch), like
>>> timelimitingcollector.
>>>
>>> --
>>> lucidimagination.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>>
>>
>> --
>> Anne Veling
>> BeyondTrees.com
>> +31 6 50 969 170
>> @anneveling
>>
>
>
>
> --
> Met vriendelijke groet,
>
> Martijn van Groningen
>
--
lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: How to best test possible performance impact of a new lucene patch
Posted by Martijn v Groningen <ma...@gmail.com>.
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 <uw...@thetaphi.de> 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 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 new
> ctor to prevent this without reusing.
> --
> Uwe Schindler
> H.-H.-Meier-Allee 63, 28213 Bremen
> http://www.thetaphi.de
>
>
>
> Martijn v Groningen <ma...@gmail.com> schrieb:
>
>> 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 <an...@beyondtrees.com> 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 guess.
>>>
>>> Anne n
>>>
>>>
>>> On Wed, Sep 7, 2011 at 15:29, Robert Muir <rc...@gmail.com> wrote:
>>>
>>>> On Wed, Sep 7, 2011 at 9:09 AM, Anne Veling <an...@beyondtrees.com>
>>>> 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
>>>> > public void collect(int doc) to
>>>> > public boolean collect(int doc)
>>>> > With a default "false" return code. If a collector returns "true" the
>>>> caller
>>>> > may stop collecting. So all normal collectors would simply return
>>>> "false".
>>>> > This could introduce some performance overhead of adding a return
>>>> value to
>>>> > the call stack, and some checking in the calling code.
>>>> > However, for some other use cases, like
>>>> >
>>>>
>>>> usually the trick here to stop collecting is to throw a
>>>> runtimeexception (your own subclass that you can catch), like
>>>> timelimitingcollector.
>>>>
>>>> --
>>>> lucidimagination.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Anne Veling
>>> BeyondTrees.com
>>> +31 6 50 969 170
>>> @anneveling
>>>
>>>
>>
>>
>> --
>> Met vriendelijke groet,
>>
>> Martijn van Groningen
>>
>
--
Met vriendelijke groet,
Martijn van Groningen
Re: How to best test possible performance impact of a new lucene patch
Posted by Anne Veling <an...@beyondtrees.com>.
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.willnauer@googlemail.com> wrote:
> 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 <uw...@thetaphi.de> 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 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
> new
> > ctor to prevent this without reusing.
> > --
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, 28213 Bremen
> > http://www.thetaphi.de
> >
> >
> >
> > Martijn v Groningen <ma...@gmail.com> schrieb:
> >>
> >> 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 <an...@beyondtrees.com> 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 guess.
> >>> Anne n
> >>>
> >>> On Wed, Sep 7, 2011 at 15:29, Robert Muir <rc...@gmail.com> wrote:
> >>>>
> >>>> On Wed, Sep 7, 2011 at 9:09 AM, Anne Veling <an...@beyondtrees.com>
> >>>> 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
> >>>> > public void collect(int doc) to
> >>>> > public boolean collect(int doc)
> >>>> > With a default "false" return code. If a collector returns "true"
> the
> >>>> > caller
> >>>> > may stop collecting. So all normal collectors would simply return
> >>>> > "false".
> >>>> > This could introduce some performance overhead of adding a return
> >>>> > value to
> >>>> > the call stack, and some checking in the calling code.
> >>>> > However, for some other use cases, like
> >>>> >
> >>>>
> >>>> usually the trick here to stop collecting is to throw a
> >>>> runtimeexception (your own subclass that you can catch), like
> >>>> timelimitingcollector.
> >>>>
> >>>> --
> >>>> lucidimagination.com
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Anne Veling
> >>> BeyondTrees.com
> >>> +31 6 50 969 170
> >>> @anneveling
> >>>
> >>
> >>
> >>
> >> --
> >> Met vriendelijke groet,
> >>
> >> Martijn van Groningen
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Anne Veling
BeyondTrees.com
+31 6 50 969 170
@anneveling
Re: How to best test possible performance impact of a new lucene patch
Posted by Simon Willnauer <si...@googlemail.com>.
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 <uw...@thetaphi.de> 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 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 new
> ctor to prevent this without reusing.
> --
> Uwe Schindler
> H.-H.-Meier-Allee 63, 28213 Bremen
> http://www.thetaphi.de
>
>
>
> Martijn v Groningen <ma...@gmail.com> schrieb:
>>
>> 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 <an...@beyondtrees.com> 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 guess.
>>> Anne n
>>>
>>> On Wed, Sep 7, 2011 at 15:29, Robert Muir <rc...@gmail.com> wrote:
>>>>
>>>> On Wed, Sep 7, 2011 at 9:09 AM, Anne Veling <an...@beyondtrees.com>
>>>> 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
>>>> > public void collect(int doc) to
>>>> > public boolean collect(int doc)
>>>> > With a default "false" return code. If a collector returns "true" the
>>>> > caller
>>>> > may stop collecting. So all normal collectors would simply return
>>>> > "false".
>>>> > This could introduce some performance overhead of adding a return
>>>> > value to
>>>> > the call stack, and some checking in the calling code.
>>>> > However, for some other use cases, like
>>>> >
>>>>
>>>> usually the trick here to stop collecting is to throw a
>>>> runtimeexception (your own subclass that you can catch), like
>>>> timelimitingcollector.
>>>>
>>>> --
>>>> lucidimagination.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Anne Veling
>>> BeyondTrees.com
>>> +31 6 50 969 170
>>> @anneveling
>>>
>>
>>
>>
>> --
>> Met vriendelijke groet,
>>
>> Martijn van Groningen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: How to best test possible performance impact of a new lucene patch
Posted by Uwe Schindler <uw...@thetaphi.de>.
...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 new ctor to prevent this without reusing.
--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de
Martijn v Groningen <ma...@gmail.com> schrieb:
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 <an...@beyondtrees.com> 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 guess.
Anne n
On Wed, Sep 7, 2011 at 15:29, Robert Muir <rc...@gmail.com> wrote:
On Wed, Sep 7, 2011 at 9:09 AM, Anne Veling <an...@beyondtrees.com> 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
> public void collect(int doc) to
> public boolean collect(int doc)
> With a default "false" return code. If a collector returns "true" the caller
> may stop collecting. So all normal collectors would simply return "false".
> This could introduce some performance overhead of adding a return value to
> the call stack, and some checking in the calling code.
> However, for some other use cases, like
>
usually the trick here to stop collecting is to throw a
runtimeexception (your own subclass that you can catch), like
timelimitingcollector.
--
lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
--
Anne Veling
BeyondTrees.com
+31 6 50 969 170
@anneveling
--
Met vriendelijke groet,
Martijn van Groningen
Re: How to best test possible performance impact of a new lucene patch
Posted by Martijn v Groningen <ma...@gmail.com>.
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 <an...@beyondtrees.com> 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
> guess.
>
> Anne n
>
>
> On Wed, Sep 7, 2011 at 15:29, Robert Muir <rc...@gmail.com> wrote:
>
>> On Wed, Sep 7, 2011 at 9:09 AM, Anne Veling <an...@beyondtrees.com> 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
>> > public void collect(int doc) to
>> > public boolean collect(int doc)
>> > With a default "false" return code. If a collector returns "true" the
>> caller
>> > may stop collecting. So all normal collectors would simply return
>> "false".
>> > This could introduce some performance overhead of adding a return value
>> to
>> > the call stack, and some checking in the calling code.
>> > However, for some other use cases, like
>> >
>>
>> usually the trick here to stop collecting is to throw a
>> runtimeexception (your own subclass that you can catch), like
>> timelimitingcollector.
>>
>> --
>> lucidimagination.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
>
> --
> Anne Veling
> BeyondTrees.com
> +31 6 50 969 170
> @anneveling
>
>
--
Met vriendelijke groet,
Martijn van Groningen
Re: How to best test possible performance impact of a new lucene patch
Posted by Robert Muir <rc...@gmail.com>.
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 <an...@beyondtrees.com> 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
> guess.
> Anne
>
> On Wed, Sep 7, 2011 at 15:29, Robert Muir <rc...@gmail.com> wrote:
>>
>> On Wed, Sep 7, 2011 at 9:09 AM, Anne Veling <an...@beyondtrees.com> 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
>> > public void collect(int doc) to
>> > public boolean collect(int doc)
>> > With a default "false" return code. If a collector returns "true" the
>> > caller
>> > may stop collecting. So all normal collectors would simply return
>> > "false".
>> > This could introduce some performance overhead of adding a return value
>> > to
>> > the call stack, and some checking in the calling code.
>> > However, for some other use cases, like
>> >
>>
>> usually the trick here to stop collecting is to throw a
>> runtimeexception (your own subclass that you can catch), like
>> timelimitingcollector.
>>
>> --
>> lucidimagination.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
>
> --
> Anne Veling
> BeyondTrees.com
> +31 6 50 969 170
> @anneveling
>
>
--
lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: How to best test possible performance impact of a new lucene patch
Posted by Anne Veling <an...@beyondtrees.com>.
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 <rc...@gmail.com> wrote:
> On Wed, Sep 7, 2011 at 9:09 AM, Anne Veling <an...@beyondtrees.com> 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
> > public void collect(int doc) to
> > public boolean collect(int doc)
> > With a default "false" return code. If a collector returns "true" the
> caller
> > may stop collecting. So all normal collectors would simply return
> "false".
> > This could introduce some performance overhead of adding a return value
> to
> > the call stack, and some checking in the calling code.
> > However, for some other use cases, like
> >
>
> usually the trick here to stop collecting is to throw a
> runtimeexception (your own subclass that you can catch), like
> timelimitingcollector.
>
> --
> lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Anne Veling
BeyondTrees.com
+31 6 50 969 170
@anneveling
Re: How to best test possible performance impact of a new lucene patch
Posted by Robert Muir <rc...@gmail.com>.
On Wed, Sep 7, 2011 at 9:09 AM, Anne Veling <an...@beyondtrees.com> 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
> public void collect(int doc) to
> public boolean collect(int doc)
> With a default "false" return code. If a collector returns "true" the caller
> may stop collecting. So all normal collectors would simply return "false".
> This could introduce some performance overhead of adding a return value to
> the call stack, and some checking in the calling code.
> However, for some other use cases, like
>
usually the trick here to stop collecting is to throw a
runtimeexception (your own subclass that you can catch), like
timelimitingcollector.
--
lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: How to best test possible performance impact of a new lucene patch
Posted by Anne Veling <an...@beyondtrees.com>.
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)
With a default "false" return code. If a collector returns "true" the caller
may stop collecting. So all normal collectors would simply return "false".
This could introduce some performance overhead of adding a return value to
the call stack, and some checking in the calling code.
However, for some other use cases, like
- checking to see if a term actually has occurrences (to filter a
suggested-terms list quickly), including possible applied facets, or
- getting a paged result list for which order or sorting is not
important, like having a lazy result block
- facet overlap computation (venn diagrams)
This would have a signficant (order of magnitude) performance improvement
for large indexes. Those are the kind of use cases that I think get more and
more important.
Of course, this trick could be implemented by a new class LazyCollector as
well of course, possibly wrapping older Collector objects to it, but I
wanted to test out the functionality first and then worry about the best way
to integrate this with the existing lucene code base. The impact on changing
the Collector interface on existing integrations and lucene user code is
significant too
I will keep you guys posted on progress, thanks,
Anne
On Wed, Sep 7, 2011 at 14:34, Michael McCandless
<lu...@mikemccandless.com>wrote:
> 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 (which we need to fix)...
>
> If you open a Jira issue and attach a patch I'd be happy to performance
> test it.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Wed, Sep 7, 2011 at 3:35 AM, Anne Veling <an...@beyondtrees.com> wrote:
> > 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 some use cases, but my change may have a negative
> effect
> > on other use cases (though I doubt it), including memory resources. Of
> > course such an effect would only be measurable for larger index sizes.
> > My question is: how can I best test this? Is there a common dataset/index
> > that is used to verify that patches do not degrade search performance? I
> can
> > do some testing on my own wikipedia index of course, but I guess that
> > aligning with the performance tools you guys are using, will be better
> > Thank you, keep up the good work,
> > Anne
> >
> > --
> > Anne Veling
> > BeyondTrees.com
> > +31 6 50 969 170
> > @anneveling
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Anne Veling
BeyondTrees.com
+31 6 50 969 170
@anneveling
Re: How to best test possible performance impact of a new lucene patch
Posted by Michael McCandless <lu...@mikemccandless.com>.
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 (which we need to fix)...
If you open a Jira issue and attach a patch I'd be happy to performance test it.
Mike McCandless
http://blog.mikemccandless.com
On Wed, Sep 7, 2011 at 3:35 AM, Anne Veling <an...@beyondtrees.com> wrote:
> 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 some use cases, but my change may have a negative effect
> on other use cases (though I doubt it), including memory resources. Of
> course such an effect would only be measurable for larger index sizes.
> My question is: how can I best test this? Is there a common dataset/index
> that is used to verify that patches do not degrade search performance? I can
> do some testing on my own wikipedia index of course, but I guess that
> aligning with the performance tools you guys are using, will be better
> Thank you, keep up the good work,
> Anne
>
> --
> Anne Veling
> BeyondTrees.com
> +31 6 50 969 170
> @anneveling
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org