You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Jukka Zitting (JIRA)" <ji...@apache.org> on 2013/07/19 12:54:49 UTC

[jira] [Resolved] (OAK-922) Optimize UpdateManyChildNodesTest

     [ 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