[
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
