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
