jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-8141) Replace String path with custom data type
Date Thu, 04 Apr 2019 13:53:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809878#comment-16809878

Marcel Reutegger commented on OAK-8141:

bq. MemoryDiffCache.Key : noticed that the compareTo uses "return early" while NamePathRev.compareTo

I don't have a preference, but I think it's better to have some consistency. I'll change it
to return early in the various implementations.

bq. Path has a compareTo - while PathComparator does p1.toString().compareTo(p2.toString()).
I'm wondering why there are 2 different approaches to comparing a Path?

Good point. {{Path.compareTo()}} is used only by the new persistent cache serialization introduced
with these changes and was free to define any ordering, while {{PathComparator}} was already
there before and had predefined semantics required by UnsavedModifications. It may be possible
to replace {{PathComparator}} with the {{Path.compareTo}} implementation. I'll check that...

> Replace String path with custom data type
> -----------------------------------------
>                 Key: OAK-8141
>                 URL: https://issues.apache.org/jira/browse/OAK-8141
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: documentmk
>            Reporter: Marcel Reutegger
>            Assignee: Marcel Reutegger
>            Priority: Major
>             Fix For: 1.12.0
>         Attachments: OAK-8141.patch
> DocumentNodeState objects and other related data is currently identified with a String
path in the various caches in the DocumentNodeStore. Read benchmarks like GetDeepNodeTest
that only read data from memory are significantly slower on a DocumentNodeStore compared to
a SegmentNodeStore. In these kind of tests the DocumentNodeStore is usually busy with String
operations like constructing the path for a child node or calculating the hash code for a
lookup in a cache.
> This issue is about a potential improvement that replaces the use of a plain String for
the path of a DocumentNodeState and use a custom Path type instead.

This message was sent by Atlassian JIRA

View raw message