Change the way raw values are preserved in TryParse #5960
Merged
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.
Bug
Related: NuGet/Home#12728
Description
Say we have the
lib/{tfm}/{assembly}
patternDuring the TokenSegment.TryParse method if we encounter a tfm, we store the parsed tfm value in the ContentItem to pick the best group later. We also store the tfm_raw in some cases, since we need it in pack. Now since this is only needed during pack, we don't need to store and create string allocations during restore.
The implementation isn't a design I love, but something that we're constrained to due to our public APIs. Open to other suggestions if people have any.
In general server team and SDK team would use the ManagedCodeConventions specified by default and used during restore. In order to not break that, I removed tfm_raw allocations completely in the general codepath.
A PatternDefintion carries the knowledge that the parser needs to preserve the raw values. I added it as an init property to avoid breaking the constructor or a lot of code duplication. The fact that it's an init property keeps it immutable.
As part of this work, I also null annotated ContentQueryDefinition and improved the allocations in the constructor. This saves only few hundred KBs so it wasn't worth calling out.
Total, this shaves off about 10MB during an OrchardCore restore.
Before:
After:
Note that this removes: + system.memory.ni? which is the string actualization from ReadOnlyMemory in the specific TryMatch method.
After I think the only realistic allocation reductions that don't completely involve refactoring all of the assets selection are the dictionary usages.
Some micro benchmarks. The improvements are more significant there.
PR Checklist
Added testsTests exist.