Speed up multiple attributes overwrite detection. Fixes #24467 #24561
Conversation
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
SteveSandersonMS
force-pushed
the
stevesa/perf-faster-attribute-splatting
branch
2 times, most recently
from
deb9eae to
98aac4c
Compare
SteveSandersonMS
force-pushed
the
stevesa/perf-faster-attribute-splatting
branch
from
98aac4c to
dd42509
Compare
captainsafia
reviewed
Aug 5, 2020
| for (var i = last; i >= first; i--) | ||
| { | ||
| ref var frame = ref buffer[i]; | ||
| Debug.Assert(frame.FrameTypeField == RenderTreeFrameType.Attribute, $"Frame type is {frame.FrameTypeField} at {i}"); | ||
|
|
||
| if (!seenAttributeNames.TryGetValue(frame.AttributeNameField, out var index)) | ||
| if (!seenAttributeNames.TryAdd(frame.AttributeNameField, i)) |
captainsafia
reviewed
Aug 5, 2020
| // proportion of attribute names. | ||
| return unchecked( | ||
| char.ToLowerInvariant(key[keyLength - 1]) | ||
| + 31 * char.ToLowerInvariant(key[keyLength / 2]) |
There was a problem hiding this comment.
Can we assign the coefficients here to constants?
There was a problem hiding this comment.
Generally I'd prefer not to add the extra abstraction unless it's a case where we think there are multiple uses that need to be kept in sync. Let me know if you want to discuss it - maybe there are other reasons I'm missing!
There was a problem hiding this comment.
I posted the feedback in the interest of readability. I totally hear you about it not being technically necessary. Maybe the middleware group is an inline comment (e.g. 42 /* LIFE_THE_UNIVERSE_AND_EVERYTHING */)
captainsafia
approved these changes
Aug 5, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Details in #24467
I spent ages on this because there were so many ways to approach it. The awkward thing is I can actually make this quite noticeably faster still than the code in this PR, by implementing:
System.Collections.Generic.Dictionary<T,U>, but a different implementation altogether). This gives about another 2.5% gain on the benchmark on top of this PR.char.ToLowerInvariantthat special-cases ASCII, but falls back onchar.ToLowerInvariantfor other inputs. This gives another 1% gain.However after some wrangling I've decided not to do either of those. It's because even if my implementations are faster on the benchmark scenarios today, it's possible that:
System.Collections.Generic.Dictionaryin all extreme cases is well understood, but we can't say the same for new alternatives.char.ToLowerInvariantcan be expected to get faster, whereas custom implementations won't.So, the code as-is in this PR improves intensive attribute splatting scenarios by around 5%. Not just the attribute-splatting part of the process, but the timings of the entire scenario that involves intensive attribute splatting. That's pretty worthwhile even if we forgo the extra ~3.5% we could get with a custom dictionary and char-normalizer.