[
https://issues.apache.org/jira/browse/OAK-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885457#comment-13885457
]
Michael Dürig commented on OAK-1361:
------------------------------------
Thanks Marcel. This improves my figures a lot.
On scenario I was looking at simulates the situation where 100 event handlers
are blocked for a while and then have to catch up with 100 commits of 1000
nodes each. While not necessarily realistic the result from profiling are
nevertheless interesting. I see the following stack trace coming up a lot:
{code}
"Name","Time (ms)","Samples","Level"
"org.apache.jackrabbit.oak.plugins.document.DocumentNodeState.compareAgainstBaseState(NodeState,
NodeStateDiff)","188784","1302", "17"
"org.apache.jackrabbit.oak.spi.state.AbstractNodeState.getChildNodeCount(long)","178487","1242",
"18"
"org.apache.jackrabbit.oak.plugins.document.DocumentNodeState$2.iterator()","172495","1202",
"19"
"org.apache.jackrabbit.oak.plugins.document.DocumentNodeState$ChildNodeEntryIterator.<init>(DocumentNodeState)","172495","1202",
"20"
"org.apache.jackrabbit.oak.plugins.document.DocumentNodeState$ChildNodeEntryIterator.fetchMore()","172495","1202",
"21"
{code}
In fact 94% of CPU is spent in {{AbstractNodeState.getChildNodeCount(long)}}.
> DocumentNodeState#compareAgainstBaseState too slow
> --------------------------------------------------
>
> Key: OAK-1361
> URL: https://issues.apache.org/jira/browse/OAK-1361
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
> Reporter: Michael Dürig
> Assignee: Marcel Reutegger
> Labels: observation
> Fix For: 0.16
>
>
> {{DocumentNodeState#compareAgainstBaseState}} usually falls back to the
> default implementation in
> {{AbstractNodeState#compareAgainstBaseState(NodeState, NodeStateDiff)}},
> which is slow. See also the TODO in the code. This negatively affects
> performance when generation observation events.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
