Conversation
The zero-padded benchmark ID makes it easy to run ranges of benchmarks, e.g., to run benchmarks on inputs shorter than 100 bytes, run the “/00” benchmarks.
This adds a conservative check to `fill` which will avoid wrapping the input when it is a single line which is shorter than the wrap width. In that case, wrapping the input is now 10-25 times faster than before. The input length is measured in bytes, which means that we can overestimate the length compared `display_width`. This is because multi-byte sequences (such as combining diacritics) can be displayed as a single character. So we will end up taking the slow path for some strings, but the vast majority of short strings will take the fast path. The correctness of the fast path is checked with a new fuzz test.
This speeds up wrapping of multi-line inputs since each line can be returned as-is when no wrapping is needed. The `wrap` function is now up to 10 times faster when it sees that no wrapping is needed. The correctness of the fast-path is checked with a new fuzz test.
This module is only present when running fuzz tests.
This was referenced Oct 23, 2022
Merged
Closed
Merged
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.
In case the input is shorter than the wrapping width, we can return it immediately. This avoids findings words, breaking them, and finally reassembling them.
The speedup from the is on the order of 10-25 times, depending on the wrapping width. I tested with a wrapping width of 60 columns and there the time for
fill("")is now around 15 nanoseconds. It was around 150 nanoseconds before:A similar 10x improvement is seen for
fill("abcde"):As strings get longer and closer to the wrapping width, the improvements get larger. Before it took just shy of a microsecond to wrap a 50 character string on my machine:
Now it only takes 34 nanoseconds, a 27x improvement:
The time needed to wrap the input is nearly flat until you hit the wrapping width, as which time it grows linearly with the input length: