[YANGTOOLS-1497] Improve NamespaceBehaviour/NamespaceStorageNode interactions

Blocks — Thu, 6 Apr 2023 16:23:28 +0000

As examined in ~~YANGTOOLS-1159~~, ~~YANGTOOLS-1204~~ and other places, we spend a significant amount of time traversing the NamespaceStorageNode tree towards root in order to find things that are shared either on source-local, module-local or global scope.

At the end of the day, for any ParserNamespace operation, we have to find its NamespaceBehaviour and then execute the request using that behaviour.

There is a connection between these operations, at least in the yang-parser-reactor implementation. The story goes something like this:

there are 4 StorageNodeTypes
we have a single baseline NamespaceStorageNode implementation (NamespaceStorageSupport), which is subclassed
there is the notion of NamespaceBehaviour.Registry, of which we have three implementations:
1. BuildGlobalContext, which also is the only StorageNodeType.GLOBAL
2. SourceSpecificContext, which also is the only StorageNodeType.SOURCE_LOCAL_SPECIAL
3. StatementSupportBundle, which seems to be quite unrelated to this problem, but has interaction with BuildGlobalContext
StorageNodeType.ROOT_STATEMENT_LOCAL is only implemented by RootStatementContext
StorageNodeType.STATEMENT_LOCAL by all other ReactorStmtCtx subclasses

The behaviour count breaks down as follows:

global() has 19 references (GLOBAL node)
sourceLocal() has 6 references (SOURCE_LOCAL_SPECIAL node)
statementLocal() has 7 references (STATEMENT_LOCAL node)
rootStatementLocal() has 3 references (ROOT_STATEMENT_LOCAL node)
treeScoped() has 2 references (which means the first match node along ancestor axis)

The yang-parser-reactor implementation essentially requires a walk to BuildGlobalContext to acquire NamespaceBehaviours, which it wraps with extended implementations (Simple/VirtualNamespaceContext) – hence these implementations are primed to have a quick way to access the GLOBAL node. Furthermore RootStatementContext has a direct pointer to SourceSpecificContext and that has a direct pointer to BuildGlobalContext.

Based on these implementation specifics, there seems to be an opportunity to knock off at least the global() case in that we would memoize BuildGlobalContext reference in NamespaceContexts – and then we just need to provide a mechanism for them to provide access to it to their respective NamespaceBehaviours.

This will provide immediate benefits to major users:

SUPPORTED_FEATURES, which is behind ReactorStmtCtx.isSupportedByFeatures()
FEATURE, which does the the same
MODULECTX_TO_QNAME, which participates on local QName construction

as these will not have to walk the statement tree again to reach BuildGlobalContext.

While there may be other opportunities, this issue should focus on:

disconnecting StatementSupportBundle and NamespaceBehaviour.Registry
perhaps making NamespaceBehaviour.Registry a yang-parser-reactor-internal thing
providing a way for NamespaceBehaviour.global() to receive BuildGlobalContext reference without traversing NamespaceStorageNode tree

OpenDaylight JIRA

[YANGTOOLS-1497] Improve NamespaceBehaviour/NamespaceStorageNode interactions