Improve performance of enumerating constraint-bound attributes consistent across many runs #1226
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.
Attributes bound to particular run boundaries (paragraphs, characters, etc.) are guaranteed to have consistent values between each boundary. This invariant is enforced at mutation time so that reading the attributed string can take advantage of this information. One place where we have yet to take advantage of this is when enumerating runs sliced to a particular attribute (for example
attrStr.runs[\.someParagraphConstrainedAttribute]
). Currently, we follow these steps to find the end of a coalesced run:However, since we know that attribute values must be consistent up to the next constraint boundary, there's no need to look at the attribute values at all! If we are only dealing with a single kind of run boundary (for any number of attributes) we can just find the next constraint break (within the current discontiguous slice chunk) and return that without spending time comparing attribute values (which can be quite expensive). I added some benchmarks that show quite a bit of improvement in this area with these updates:
The long run benchmarks are unchanged (because they don't spend a lot of time comparing attribute values) but these changes don't regress them in any way.
rdar://146903366