Improve performance for comparing AttributedStrings with differing character counts #1224
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.
Two
AttributedString
s with differing character counts will never compare equal. When we can cheaply determine that the character counts are inequal, we should return early fromAttributedString.==
rather than comparing each runs contents. This situation can be quite common (for example, just appending a single character to the end of the last run like when a user types into a text box) and it turns a full run-by-run comparison of the entire string into a single constant time evaluation. The benchmark results highlight that for this worst-case, but common, scenario the wins are significant:Note: there's an explanation left in the comments of the code but this optimization is currently only performed for
AttributedString.==
and not forAttributedSubstring.==
orDiscontiguousAttributedSubstring.==
.