[ https://issues.apache.org/jira/browse/OAK-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting resolved OAK-922. ------------------------------- Resolution: Fixed Fix Version/s: 0.9 And in http://svn.apache.org/r1504822 I adjusted the SegmentMK to avoid making a full copy of a long multi-valued property when only some entries have changed. The result: {noformat} # UpdateManyChildNodesTest min 10% 50% 90% max N Oak-Tar 27 28 29 32 62 1007 {noformat} That's roughly equivalent to Jackrabbit performance, so I think we're good here, especially as supporting efficient updates to flat, *orderable* nodes is not one of our goals. For comparison, if I change the test to use the unorderable {{oak:unstructured}} type instead of the orderable {{nt:unstructured}}, Oak is way faster than Jackrabbit thanks to the flat hierarchy support: {noformat} # UpdateManyChildNodesTest min 10% 50% 90% max N Oak-Tar 0 0 1 1 18 32835 {noformat} > Optimize UpdateManyChildNodesTest > --------------------------------- > > Key: OAK-922 > URL: https://issues.apache.org/jira/browse/OAK-922 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core > Reporter: Jukka Zitting > Assignee: Jukka Zitting > Fix For: 0.9 > > > The {{UpdateManyChildNodesTest}} benchmark looks pretty bad for Oak: > {noformat} > # UpdateManyChildNodesTest min 10% 50% 90% max N > Jackrabbit 12 14 17 36 486 1263 > Oak-Tar 380 458 483 548 1079 61 > {noformat} > The main culprits are an O(n^2) algorithm in {{ChildOrderDiff}}, an O\(n) > comparison in {{AbstractPropertyState.equals()}} and some missing SegmentMK > optimizations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira