[MDSAL-443] Inline CodecDataObject's NodeContextSuppliers Created: 23/Apr/19  Updated: 09/Jan/24

Status: Confirmed
Project: mdsal
Component/s: Binding runtime
Affects Version/s: None
Fix Version/s: 14.0.0

Type: Improvement Priority: Medium
Reporter: Robert Varga Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: pt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
blocks MDSAL-444 Switch runtime codegen from Javassis... Resolved
is blocked by MDSAL-442 Teach binding-dom-codec to keep its p... Resolved
is blocked by MDSAL-669 Retain grouping/uses instantiation ve... Resolved

 Description   

The LazyDataObject->CodecDataObject refactor allows us to improve the dispatch performance as we are no longer bound by InvocationHandler API. First part of this was already done in MDSAL-442, where we are using simple integers to lookup NodeContextSupplier which handles decoding of NormalizedNode data – ditching a Map in favor of simple array.

As it turns out, though, we can do a bit better here, as CodecDataObject only needs that lookup from DataObjectCodecContext. Since the offsets are fixed anyway, we may as well generate constant fields in the CodecDataObject overlay and pass them down to CodecDataObject proper, which will then just use the constant.

This will eliminate all lookups from the hot path and use easily propagated constants instead. It will also save one field in CodecDataObject, as it will no longer require a reference to DataObjectCodecContext.



 Comments   
Comment by Robert Varga [ 23/Apr/19 ]

The disconnect of CodecDataObject is not complete, as we still need the DataObjectCodecContext reference for AugmentableCodecDataObject mechanics. In order to eliminate that dependency will need MDSAL-392, i.e. full visibility into all possible augmentations and their ClassLoaders. This issue will deal only with normal fields and the key() method.

Comment by Robert Varga [ 01/May/19 ]

This optimization is not valid, as it breaks the ability to transport groupings: if a grouping is used somewhere we need to rehost the NodeContextSupplier.

Hence we need to dial this optimization down, so that we understand whether a node is defined within the context of a grouping – in which case we need to fall back to name-based lookups. If a node is defined outside of a grouping, i.e. it cannot be reused, we are free to perform this optimization.

This will require some amount of refactoring to have DataObjectCodecContext the appropriate hooks to support such duality of operation.

Comment by Robert Varga [ 16/Jun/21 ]

We have everything we need in CodecDataObjectGenerator.Fixed, but we also need instantiation information from MDSAL-669.

Generated at Wed Feb 07 20:09:49 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.