Inefficient code generated from `ToString::to_string()` for `bool`

[Kmeakin]

The ToString::to_string() implementation for bool generates over 700 lines of LLVM IR and 500 lines of AArch64 assembly!
Using format! with Display or Debug is also unnecessarily inefficient.
https://godbolt.org/z/3M4jGYE9d

// Worst
pub fn to_string(b: bool) -> String {
    b.to_string()
}

// Better
pub fn format_display(b: bool) -> String {
    format!("{b}")
}

pub fn format_debug(b: bool) -> String {
    format!("{b:?}")
}

// Best
pub fn if_then_else(b: bool) -> String {
    if b {
        "true".into()
    } else {
        "false".into()
    }
}

Version

rustc 1.68.0-nightly (ee0412d1e 2023-01-07)
binary: rustc
commit-hash: ee0412d1ef81efcfabe7f66cd21476ca85d618b1
commit-date: 2023-01-07
host: x86_64-unknown-linux-gnu
release: 1.68.0-nightly
LLVM version: 15.0.6

[Ezrashaw]

Hmm, internally Display and Debug for bool are just an if/else statement, ToString is then implemented for any types implementing those. I wonder if this overhead:

#[inline]
default fn to_string(&self) -> String {
    let mut buf = String::new();
    let mut formatter = core::fmt::Formatter::new(&mut buf);
    // Bypass format_args!() to avoid write_str with zero-length strs
    fmt::Display::fmt(self, &mut formatter)
        .expect("a Display implementation returned an error unexpectedly");
    buf
}

causes that issue. Perhaps bool can be special-cased in ToString (like many other types)?

I'm happy to do a PR for this, just want confirmation this is sane.

[Noratrieb]

Going through the formatting machinery causes lots of overhead since there's a lot of dynamic dispatch going on. We could specialize ToString on bool to return the string directly here.

[Ezrashaw]

Cool, I assume I can copy from bool's Display impl.

@rustbot claim