Hi,
Thanks for looking at this, sounds like you are on the case already.
if I see anything else I'll let you know.
Best Regards
Ian


On 15 September 2016 at 05:33, Chetan Mehrotra <chetan.mehro...@gmail.com>
wrote:

> Note that so far LuceneIndexEditor was used only for async indexing
> case and hence invoked only on leader node every 5 sec. So performance
> aspects here were not that critical. However with recent work on
> Hybrid indexes they would be used in critical path and hence such
> aspects are important
>
> On Wed, Sep 14, 2016 at 3:10 PM, Ian Boston <i...@tfd.co.uk> wrote:
> > A and B mean that the work of creating the tree and working out the
> changes
> > in a tree will be duplicated roughly n times, where n is the number of
> > index definitions.
>
> Here note that diff would be performed only once at any level and
> IndexUpdate would then pass them to various editors. However
> construction of trees can be avoided and I have opened OAK-4806 for
> that now. Oak issue has details around why Tree was used also.
>
> Also with multiple index editors performance does decrease. See
> OAK-1273. If we switch to Hybrid Index then this aspects improves a
> bit as instead of having 50 different property indexes (with 50 editor
> instance for each commit) we can have a single editor with 50 property
> definition. This can be seen in benchmark in Hybrid Index (OAk-4412)
> by changing the numOfIndexes
>
> If you see any other area of improvement say around unnecessary object
> generation then let us know!
>
> Chetan Mehrotra
>

Reply via email to