[
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)
