Repository navigation
Resolve the xsi:type cache key without building the detected type - #82
Merged
Merged
Conversation
The encoder cache key only needs the namespace, the local name and the slot meta. I now read those from the element and only build the XsdType copy when the cache misses.
The slot part of the cache key only depends on the context, which is fixed for an iso. XsiTypeEncoder now asks the detector for a per context detector when it builds its iso, so decoding an element only parses the xsi:type and does the cache lookup.
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 40 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
On a use=encoded response every element carries an xsi:type, and
XsiTypeEncoderasksXsiTypeDetectorfor the matching encoder on each one. The encoder itself already comes from theScopedCache, but to build the cache key the detector first cloned the slot type three times into the detected type and then read six meta flags from it. Those flags belong to the slot, so they are the same for every element the iso decodes.The detector now reads the namespace and local name from the element and only builds the detected type on a cache miss.
XsiTypeEncoder::iso()also gets a small detector closure fromXsiTypeDetector::encoderDetectorForContext()(internal), which works out the slot flags once per iso. Per element that leaves parsing the xsi:type and the cache lookup.detectEncoderFromXmlElement()anddetectXsdTypeFromXmlElement()keep their signatures and results.Cache key
The key string is the same as on main: namespace URI, local name of the xsi:type and the slot meta flags (element, attribute, nullable, list, qualified, simple). I only build it in two halves now. It stays in the existing per registry
ScopedCache, and no element value goes into it. The closure holds the slot flags and the context, nothing that grows with the payload.Speed
phpbench, median of 3 interleaved runs, x500 subjects:
The 3MB literal workloads also run through
XsiTypeEncoderfor every item, so they gain a little as well. Seconds, median of 3 interleaved rounds:Encode on the 3MB workloads stays within 3% either way.