core: respect precision in ByteStr Display#153025
core: respect precision in ByteStr Display#153025joboet wants to merge 1 commit intorust-lang:mainfrom
ByteStr Display#153025Conversation
|
r? @jhpratt rustbot has assigned @jhpratt. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
@bors try @rust-timer queue Just to get ahead of potential perf (shouldn't block merging as a correctness fix). |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
core: respect precision in `ByteStr` `Display`
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (2448715): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 1.1%, secondary 4.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 7.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.0%, secondary 0.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 479.41s -> 478.565s (-0.18%) |
Fixes #153022.
ByteStr'sDisplayimplementation didn't respect the precision parameter. Just likeFormatter::pad, this is fixed by counting off the characters in the string and truncating after the requested length – with the added complication that theByteStrneeds to be divided into chunks first. By including a fast path that avoids counting the characters when no parameters were specified this should also fix the performance regressions caused by #152865.