[ https://issues.apache.org/jira/browse/OAK-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15888182#comment-15888182 ]
Michael Dürig commented on OAK-5853: ------------------------------------ Running benchmarks shows that performance is actually inferior with the patch: {noformat} # LoginTest C min 10% 50% 90% max N base-line 1 641 645 653 657 791 918 OAK-5853 1 642 646 652 659 721 917 # LoginLogoutTest C min 10% 50% 90% max N base-line 1 644 645 647 651 654 927 OAK-5853 1 647 649 650 654 661 922 # LoginGetRootLogoutTest C min 10% 50% 90% max N base-line 1 644 645 647 650 660 927 OAK-5853 1 648 649 650 654 661 923 # LoginSystemTest C min 10% 50% 90% max N base-line 1 6 6 7 7 16 86911 OAK-5853 1 7 7 7 8 16 81598 # LoginImpersonateTest C min 10% 50% 90% max N base-line 1 114 117 119 120 127 5039 OAK-5853 1 116 118 121 122 130 4976 # LoginWithMembershipTest C min 10% 50% 90% max N base-line 1 880 886 891 896 902 674 OAK-5853 1 900 903 907 912 916 662 # LoginWithMembersTest C min 10% 50% 90% max N base-line 1 677 680 683 685 688 879 OAK-5853 1 684 686 688 692 699 872 # SetPropertyTest C min 10% 50% 90% max N base-line 1 217 218 221 225 395 2709 OAK-5853 1 220 225 228 232 345 2627 # SetMultiPropertyTest C min 10% 50% 90% max N base-line 1 184 187 189 192 221 3162 OAK-5853 1 191 193 196 199 227 3055 # SmallFileWriteTest C min 10% 50% 90% max N base-line 1 21 22 22 23 374 20670 OAK-5853 1 21 22 23 24 376 20401 # ConcurrentReadWriteTest C min 10% 50% 90% max N base-line 1 25 41 48 99 214 9944 OAK-5853 1 23 39 47 97 569 10151 # ConcurrentWriteReadTest C min 10% 50% 90% max N base-line 1 3 5 6 27 246 50773 OAK-5853 1 3 6 7 31 240 46057 # ConcurrentWriteTest C min 10% 50% 90% max N base-line 1 82 84 85 92 387 6927 OAK-5853 1 93 95 96 103 245 6122 # FlatTreeUpdateTest C min 10% 50% 90% max N base-line 1 6866 6914 6993 7011 7120 86 OAK-5853 1 33340 33356 33907 33993 34032 18 # CreateManyChildNodesTest C min 10% 50% 90% max N base-line 1 540 544 549 553 672 890 OAK-5853 1 554 559 564 570 685 872 # CreateManyNodesTest C min 10% 50% 90% max N base-line 1 171 175 179 183 355 3347 OAK-5853 1 176 180 184 748 2571 1756 # UpdateManyChildNodesTest C min 10% 50% 90% max N base-line 1 0 0 0 1 186 674367 OAK-5853 1 2 3 3 3 11 97962 # TransientManyChildNodesTes C min 10% 50% 90% max N base-line 1 3 3 3 4 14 186754 OAK-5853 1 3 3 3 4 12 181237 # XmlImportTest C min 10% 50% 90% max N base-line 1 5026 5130 5658 7161 8732 101 OAK-5853 1 5046 5403 7238 10199 14684 80 # FlatTreeWithAceForSamePrin C min 10% 50% 90% max N base-line 1 18 18 18 19 27 32286 OAK-5853 1 16 16 17 17 25 35968 # ConcurrentCreateNodesTest C min 10% 50% 90% max N base-line 1 549 822 863 1144 2034 641 OAK-5853 1 569 834 1070 2341 3749 454 # SequentialCreateNodesTest C min 10% 50% 90% max N base-line 1 272 279 542 566 1438 1303 OAK-5853 1 285 290 297 551 872 1435 # CreateManyIndexedNodesTest C min 10% 50% 90% max N base-line 1 30 33 56 533 1019 3320 OAK-5853 1 64 97 261 2499 5561 839 # ConcurrentFileWriteTest C min 10% 50% 90% max N base-line 1 14 543 1251 2145 3961 472 OAK-5853 1 23 507 2286 4623 7046 249 {noformat} I assume the patch only addresses the very specific case where we end up calling {{ModifiedNodeState.getChildNodeCount(long)}} and the modifies state has many modified child entries. If this turns out to be problematic we should improve the latter method instead. > Potential expensive call to NodeState.getChildNodeCount() in constructor of > Template > ------------------------------------------------------------------------------------ > > Key: OAK-5853 > URL: https://issues.apache.org/jira/browse/OAK-5853 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: segment-tar > Reporter: Michael Dürig > Assignee: Michael Dürig > Priority: Minor > Labels: performance > Fix For: 1.8 > > Attachments: OAK_5853.patch > > > On of the {{Template}} constructors (the one used when writing templates) > performs a call to {{NodeState.getChildNodeCount()}} to determine the value > of {{Template.childName}}. I have seen this call comping up in performance > traces on various occasions, which leads me to believe there is room for > improvement here. -- This message was sent by Atlassian JIRA (v6.3.15#6346)