[jira] [Commented] (OAK-8209) Improve Node.isNodeType(String) performance
[
https://issues.apache.org/jira/browse/OAK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815273#comment-16815273
]
Marcel Reutegger commented on OAK-8209:
---
Forgot to add benchmark results.
Before:
{noformat}
java -jar target/oak-benchmarks-1.14-SNAPSHOT.jar benchmark --cache 256
IsNodeTypeTest Oak-Mongo
Apache Jackrabbit Oak 1.14-SNAPSHOT
# IsNodeTypeTest C min 10% 50% 90% max
N
Oak-Mongo 1 95 99 105 113 131
569
{noformat}
After:
{noformat}
java -jar target/oak-benchmarks-1.14-SNAPSHOT.jar benchmark --cache 256
IsNodeTypeTest Oak-Mongo
Apache Jackrabbit Oak 1.14-SNAPSHOT
# IsNodeTypeTest C min 10% 50% 90% max
N
Oak-Mongo 1 46 49 52 54 71
1159
{noformat}
> Improve Node.isNodeType(String) performance
> ---
>
> Key: OAK-8209
> URL: https://issues.apache.org/jira/browse/OAK-8209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.14.0
>
> Attachments: OAK-8209-RootTest.patch
>
>
> Profiling an application running on Oak showed calls to
> {{Node.isNodeType(String)}} as one of the hot spots. While it may be possible
> to reduce those calls there's probably also some potential in optimizing the
> implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8209) Improve Node.isNodeType(String) performance
[
https://issues.apache.org/jira/browse/OAK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815270#comment-16815270
]
Marcel Reutegger commented on OAK-8209:
---
Thanks for the confirmation Michi.
> Improve Node.isNodeType(String) performance
> ---
>
> Key: OAK-8209
> URL: https://issues.apache.org/jira/browse/OAK-8209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Attachments: OAK-8209-RootTest.patch
>
>
> Profiling an application running on Oak showed calls to
> {{Node.isNodeType(String)}} as one of the hot spots. While it may be possible
> to reduce those calls there's probably also some potential in optimizing the
> implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8209) Improve Node.isNodeType(String) performance
[
https://issues.apache.org/jira/browse/OAK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814544#comment-16814544
]
Michael Dürig commented on OAK-8209:
{quote}I guess the real question is, can I depend on this?
{quote}
Yes I think so. This should work.
{quote}[...] refresh may update the underlying node states to reflect a remove
of the tree by another session, which would be fine as well if it is really
removed.
{quote}
That's how I remember it as well. The underlying magic is implemented the way
{{MemoryNodeBuilder}} tracks transient changes. However, I'm not sure how
common this usage pattern is and thus whether you might start seeing bugs that
where hidden so far.
Re. revision GC I don't think this is a concern. We guarantee retention for >=
1 generation (24 hrs if GC runs daily). Older sessions will be refreshed
({{o.a.j.o.jcr.repository.RepositoryImpl.RefreshOnGC}}), which will cause a
refresh on the associated root
({{o.a.j.o.jcr.delegate.SessionDelegate#refresh}}). Although this refresh is
somewhat best effort (sessions might miss it because of race conditions), the
recommendation is not to keep sessions open for long without refreshing them.
The {{types}} {{Tree}} in {{WorkspaceImpl}} is not the only place causing
\{{SNFE}}s in the case of a missed refresh after GC.
> Improve Node.isNodeType(String) performance
> ---
>
> Key: OAK-8209
> URL: https://issues.apache.org/jira/browse/OAK-8209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Attachments: OAK-8209-RootTest.patch
>
>
> Profiling an application running on Oak showed calls to
> {{Node.isNodeType(String)}} as one of the hot spots. While it may be possible
> to reduce those calls there's probably also some potential in optimizing the
> implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8209) Improve Node.isNodeType(String) performance
[
https://issues.apache.org/jira/browse/OAK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814453#comment-16814453
]
Marcel Reutegger commented on OAK-8209:
---
I definitively want something that works with all node store implementations.
bq. you can get into trouble keeping a tree reference over a compaction run
(you'd start seeing SNFEs)
Wasn't this a problem related to properties? MutableTree references a
NodeBuilder, which is rebased and should be able to do so even across
compaction cycles because the underlying NodeState is replaced on rebase. At
least that's my understanding. A JCR Value on the other hand references a
PropertyState. I think keep holding of those Value or PropertyState objects was
the reason for the SNFE. The issue I have in mind is OAK-2384.
bq. my suggestion to set the tree to null on refresh, does that not fare well
with the benchmark?
It's unlikely this will have a negative impact on the benchmark, but I'm
reluctant implementing it like this when it is actually not necessary.
> Improve Node.isNodeType(String) performance
> ---
>
> Key: OAK-8209
> URL: https://issues.apache.org/jira/browse/OAK-8209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Attachments: OAK-8209-RootTest.patch
>
>
> Profiling an application running on Oak showed calls to
> {{Node.isNodeType(String)}} as one of the hot spots. While it may be possible
> to reduce those calls there's probably also some potential in optimizing the
> implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8209) Improve Node.isNodeType(String) performance
[
https://issues.apache.org/jira/browse/OAK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814376#comment-16814376
]
Alex Deparvu commented on OAK-8209:
---
I think the test is too weak to represent normal operations. The tree will
probably be valid as long as the NodeState will be available. If I remember
correctly from back in the day, you can get into trouble keeping a tree
reference over a compaction run (you'd start seeing SNFEs), but that might not
be true anymore. And this is of course segment store, for the document store
you are the expert :)
In general, a session will get refreshed, but a hard reference to a tree will
not, hence my suggestion to set the tree to null on {{refresh}}, does that not
fare well with the benchmark?
> Improve Node.isNodeType(String) performance
> ---
>
> Key: OAK-8209
> URL: https://issues.apache.org/jira/browse/OAK-8209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Attachments: OAK-8209-RootTest.patch
>
>
> Profiling an application running on Oak showed calls to
> {{Node.isNodeType(String)}} as one of the hot spots. While it may be possible
> to reduce those calls there's probably also some potential in optimizing the
> implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8209) Improve Node.isNodeType(String) performance
[
https://issues.apache.org/jira/browse/OAK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814359#comment-16814359
]
Marcel Reutegger commented on OAK-8209:
---
So, my expectation is basically what the following test confirms:
[^OAK-8209-RootTest.patch].
I guess the real question is, can I depend on this?
> Improve Node.isNodeType(String) performance
> ---
>
> Key: OAK-8209
> URL: https://issues.apache.org/jira/browse/OAK-8209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Attachments: OAK-8209-RootTest.patch
>
>
> Profiling an application running on Oak showed calls to
> {{Node.isNodeType(String)}} as one of the hot spots. While it may be possible
> to reduce those calls there's probably also some potential in optimizing the
> implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8209) Improve Node.isNodeType(String) performance
[
https://issues.apache.org/jira/browse/OAK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814348#comment-16814348
]
Marcel Reutegger commented on OAK-8209:
---
I was reading this particular documentation as well and interpreted it as, a
refresh may update the underlying node states to reflect a remove of the tree
by another session, which would be fine as well if it is really removed. Or do
we really discard all Tree instances after a rebase or refresh?
> Improve Node.isNodeType(String) performance
> ---
>
> Key: OAK-8209
> URL: https://issues.apache.org/jira/browse/OAK-8209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
>
> Profiling an application running on Oak showed calls to
> {{Node.isNodeType(String)}} as one of the hot spots. While it may be possible
> to reduce those calls there's probably also some potential in optimizing the
> implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8209) Improve Node.isNodeType(String) performance
[
https://issues.apache.org/jira/browse/OAK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814325#comment-16814325
]
Alex Deparvu commented on OAK-8209:
---
bq. The root in SessionDelegate is final. That is, the ReadWriteNodeTypeManager
can just as well remember the Tree.
I think this is not entirely correct. The delegate can call Root#rebase which
can invalidate the tree:
{noformat}
Rebase this root instance to the latest revision. After a call to this method,
trees obtained through getTree(String) may become non existing.{noformat}
I think you could work around this by setting it to null in {{refresh()}}.
> Improve Node.isNodeType(String) performance
> ---
>
> Key: OAK-8209
> URL: https://issues.apache.org/jira/browse/OAK-8209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
>
> Profiling an application running on Oak showed calls to
> {{Node.isNodeType(String)}} as one of the hot spots. While it may be possible
> to reduce those calls there's probably also some potential in optimizing the
> implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8209) Improve Node.isNodeType(String) performance
[
https://issues.apache.org/jira/browse/OAK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813530#comment-16813530
]
Marcel Reutegger commented on OAK-8209:
---
Proposed changes are on GitHub:
https://github.com/apache/jackrabbit-oak/compare/trunk...mreutegg:OAK-8209
The changes on NodeImpl only have a minor impact but still prevent creating
objects unnecessarily. The more important change with more impact on
performance is in WorkspaceImpl. The ReadWriteNodeTypeManager now remembers the
Tree at {{/jcr:system/jcr:nodeTypes}}. I'm a bit rusty with the exact semantics
of Trees, but AFAIU this is fine because a Tree reflects changes that may
happen underneath. The Root from which the Tree was previously acquired on each
call is always the same. The root in SessionDelegate is final. That is, the
ReadWriteNodeTypeManager can just as well remember the Tree.
[~mduerig], could you have a quick look and let me know what you think?
> Improve Node.isNodeType(String) performance
> ---
>
> Key: OAK-8209
> URL: https://issues.apache.org/jira/browse/OAK-8209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: jcr
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
>
> Profiling an application running on Oak showed calls to
> {{Node.isNodeType(String)}} as one of the hot spots. While it may be possible
> to reduce those calls there's probably also some potential in optimizing the
> implementation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
