« Return to Thread: [VOTE] Commit LUCENE-843 (IndexWriter performance gains)
Re: [VOTE] Commit LUCENE-843 (IndexWriter performance gains)
by Grant Ingersoll-6
::
Rate this Message:
Also, is it worth considering a couple of things:
1. Do a build version release prior to committing (i.e. 2.2.1) that
way we could isolate this change and do a separate release to 2.3. I
don't want to do releases just for the sake of releases, but I think
we should at least prepare people that the next release (i.e. the one
containing 843) has a significant change. I don't think this patch
warrants a major revision tick, but it does make sense to have people
really scrutinize it and to have them know that there are significant
gains to be had.
2. or, at a minimum, do a tag of the trunk right before committing.
I just find explicit tags make it easier to rollback or compare diffs
if need be
Note these suggestions are by no means a judgment of the quality of
the patch, just some precautions before such a big change.
-Grant
On Jul 2, 2007, at 1:31 PM, Grant Ingersoll wrote:
>
> On Jul 2, 2007, at 9:35 AM, Michael McCandless wrote:
>
>> Hi,
>>
>> I'd like to commit LUCENE-843.
>>
>> The patch has gone through a number of iterations but the final
>> version that's there now (take9) is quite a bit cleaner & simpler
>> than
>> the ones leading up to it and I believe ready.
>>
>> It provides solid indexing performance gains (between 2X-8X), but, it
>> is somewhat more complex than the current "single doc per segment"
>> approach and it does introduce a change to the index format (only
>> when
>> autoCommit=false) whereby multiple segments can share a single set of
>> term vector & stored fields files.
>>
>
> +0 for now, I will try to review tonight or tomorrow night. From
> what I gather from reading the issue, etc. it sounds great and you
> and others have put a lot of hard work into it. Also, from some
> benchmarking I have done, it seems to sit well with the notion of
> optimizing merge factor, etc. based on the amount of memory available.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@...
> For additional commands, e-mail: java-dev-help@...
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...
1. Do a build version release prior to committing (i.e. 2.2.1) that
way we could isolate this change and do a separate release to 2.3. I
don't want to do releases just for the sake of releases, but I think
we should at least prepare people that the next release (i.e. the one
containing 843) has a significant change. I don't think this patch
warrants a major revision tick, but it does make sense to have people
really scrutinize it and to have them know that there are significant
gains to be had.
2. or, at a minimum, do a tag of the trunk right before committing.
I just find explicit tags make it easier to rollback or compare diffs
if need be
Note these suggestions are by no means a judgment of the quality of
the patch, just some precautions before such a big change.
-Grant
On Jul 2, 2007, at 1:31 PM, Grant Ingersoll wrote:
>
> On Jul 2, 2007, at 9:35 AM, Michael McCandless wrote:
>
>> Hi,
>>
>> I'd like to commit LUCENE-843.
>>
>> The patch has gone through a number of iterations but the final
>> version that's there now (take9) is quite a bit cleaner & simpler
>> than
>> the ones leading up to it and I believe ready.
>>
>> It provides solid indexing performance gains (between 2X-8X), but, it
>> is somewhat more complex than the current "single doc per segment"
>> approach and it does introduce a change to the index format (only
>> when
>> autoCommit=false) whereby multiple segments can share a single set of
>> term vector & stored fields files.
>>
>
> +0 for now, I will try to review tonight or tomorrow night. From
> what I gather from reading the issue, etc. it sounds great and you
> and others have put a lot of hard work into it. Also, from some
> benchmarking I have done, it seems to sit well with the notion of
> optimizing merge factor, etc. based on the amount of memory available.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@...
> For additional commands, e-mail: java-dev-help@...
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@...
For additional commands, e-mail: java-dev-help@...
« Return to Thread: [VOTE] Commit LUCENE-843 (IndexWriter performance gains)
| Free embeddable forum powered by Nabble | Forum Help |
