[
https://issues.apache.org/jira/browse/OAK-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16567910#comment-16567910
]
Michael Dürig commented on OAK-7668:
------------------------------------
[~jsedding], I have seen this method coming up in stack traces before. So far
only in quite artificial tests, never in a production like scenario. Likely
because in most production cases the code path that requires comparing stable
ids is cut short by the code [preceding
it|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentNodeState.java#L650].
Would be good to have a benchmark that (roughly) simulates package
installation. This would allow to understand the effect of the proposed
optimisation. Do you think you could come up with something?
> Optimization: SegmentNodeState#fastEquals should compare getStableIdBytes
> instead of getStableId
> ------------------------------------------------------------------------------------------------
>
> Key: OAK-7668
> URL: https://issues.apache.org/jira/browse/OAK-7668
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
> Affects Versions: 1.9.6
> Reporter: Julian Sedding
> Priority: Minor
>
> I have observed via stack trace sampling that during the installation of a
> Vault package with many small nodes on an otherwise quiet system, about 1/4
> of stack traces had the following lines on the top (this was on Oak 1.6.11,
> but reading the code it applies equally on trunk):
> {code}
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.getStableId(SegmentNodeState.java:124)+
> at
> org.apache.jackrabbit.oak.segment.SegmentNodeState.fastEquals(SegmentNodeState.java:632)
> ...
> {code}
> I suggest comparing the result of {{SegmentNodeState#getStableIdBytes}}
> instead of {{SegmentNodeState#getStableId}}, which bypasses building the
> String representation.
> So far I have no proof in the form of a benchmark, but it seems quite clear
> that this change will result in less work being performed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)