feat: display type

[robjtede]

waiting for #71

similar to #32

[robjtede]

be nice to get rid of this allocation

[robjtede]

Short is currently assumed to use IEC (binary) units due to the motivating use case of sort -h. WDYT about that?

[wookietreiber]

How about combination:

enum ByteUnit {
    Iec,
    Si,
}

enum ByteFormat {
    /// Human readable output.
    Human(ByteUnit),

    /// For `sort -h` and friends.
    Short(ByteUnit),
}

[robjtede]

how we repr this internal isn't very important since we're exposing methods on Display

i've added a note on the iec_short method about compat with sort -h

[robjtede]

The added display benchmark shows that the additional fast path branch is worth it:

Timer precision: 41 ns
display                         fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ display_inner_display        160.4 ns      │ 738.6 ns      │ 165.7 ns      │ 169.5 ns      │ 1000    │ 32000
├─ display_bytesize_standard    160.4 ns      │ 613.6 ns      │ 169.6 ns      │ 171.3 ns      │ 1000    │ 32000
├─ display_always_pad_standard  187.8 ns      │ 402.6 ns      │ 194.3 ns      │ 196.2 ns      │ 1000    │ 32000
├─ display_bytesize_custom      251.6 ns      │ 381.8 ns      │ 262 ns        │ 262.7 ns      │ 1000    │ 16000
├─ display_always_pad_custom    249 ns        │ 10.66 µs      │ 290 ns        │ 290.4 ns      │ 1000    │ 1000

Table sorted by median ascending (lower is beter)

[robjtede]

this fast path trick was taken from std::fmt::Formatter::pad

https://doc.rust-lang.org/1.84.0/src/core/fmt/mod.rs.html#1438-1442

[robjtede]

bump @MrCroxx for review

i'm keen to get v2 prepped after this

[MrCroxx]

LGTM

Thank you for your contribution. The code is awesome. 🤩

I have no comments on the code. But may I ask where does the "short" format come from, which standard or similar library?

[robjtede]

where does the "short" format come from

we discussed a bit here #14 but i'm open to changing the name "short" to something else