write! generate longer assembly compared to format!

[pickfire]

use std::fmt::Write;

let mut s = String::new();
write!(s, "{}", 1);

seemed to be generate more assembly compared to:

let mut s = String::new();
let v = format!("{}", 1);
s.push_str(&v);

For the above example, https://rust.godbolt.org/z/KPdra8

A larger example available at https://rust.godbolt.org/z/TcsbMK

[jyn514]

cc #82397, which had to be closed because of this.

[osa1]

Comparing macro expansions, this is write!:

fn main() {
    let mut s = String::new();
    s.write_fmt(...);
}

This is format!:

fn main() {
    let mut s = String::new();
    let v = {
        let res = ::alloc::fmt::format(...);
        res
    };
    s.push_str(&v);
}

(Identical expressions replaced with ...)

There isn't a lot of difference in macro expanded code, so it seems like the difference should be as a result of inlining std::fmt::format and String::write_fmt functions.

[osa1]

MIR for write version is actually smaller in terms of lines of code (219 lines for format, 169 lines for write), but LLVM IR is larger (635 lines for format, 821 lines for write).

Comparing LLVM IRs, I see these extra function in write version that do not exist in format version:

• <&mut W as core::fmt::Write>::write_char
• <&mut W as core::fmt::Write>::write_fmt
• <&mut W as core::fmt::Write>::write_str
• alloc::vec::Vec<T,A>::reserve

As far as I can see format version doesn't have any functions that don't also exist in write version.

[osa1]

Trying to understand why the functions mentioned in my previous comment are generated for the write! version. Write implementation of String:

impl fmt::Write for String {
    #[inline]
    fn write_str(&mut self, s: &str) -> fmt::Result {
        self.push_str(s);
        Ok(())
    }

    #[inline]
    fn write_char(&mut self, c: char) -> fmt::Result {
        self.push(c);
        Ok(())
    }
}

this uses the default write_fmt implementation:

pub trait Write {
    ...

    fn write_fmt(mut self: &mut Self, args: Arguments<'_>) -> Result {
        write(&mut self, args)
    }
}

In the repro, the default write_fmt is inlined, and for the write(...) call we need a vtable as the first argument is &mut dyn Write:

pub fn write(output: &mut dyn Write, args: Arguments<'_>) -> Result {
    ...
}

If I'm reading the LLVM IR right, the three LLVM functions mentioned in my previous comment, write_char, write_fmt, and write_str are for this dyn argument (vtable).

If I add inline(never) to write_fmt method then the code gets smaller, but we still need the vtables somewhere, so I think it must be moving the vtable implementation from the user's code to the library's code. Final executable should have about the same size.

If I'm right that the extra code is due to the vtable methods, then I think the code size difference should not matter too much. We could easily reduce it with an inline(never) but that would just move the vtable methods to alloc from user code. Final executables that use these methods should be about the same.

However, in a multi-crate build, I'm guessing initially each crate could generate these duplicate vtable methods, which would be de-duplicated at link time. To avoid that perhaps it would make sense to move the code to alloc.

So I think it might make sense to add a inline(never) to the default write_fmt implementation.

I don't have a lot of experience with LLVM so please let me know if I'm not making any sense :)

Does anyone have any opinions on this?

Would it make sense to open a PR just to evaluate this? (adding inline(never) to the default write_fmt)

[jyn514]

Would it make sense to open a PR just to evaluate this? (adding inline(never) to the default write_fmt)

Yes, that sounds useful :) and if the benchmarks don't show a noticable change you could tack on the rustdoc change I mentioned above, which stresses write! quite a lot.

[osa1]

@jyn514

and if the benchmarks don't show a noticable change you could tack on the rustdoc change I mentioned above, which stresses write! quite a lot.

How do I test #82397 with my PR?

[jyn514]

@osa1 rustdoc uses the in-tree version of the standard library, so it will use any change you make. Any perf runs that end with -doc measure rustdoc's performance. You can see exactly what changed by clicking on the percentage. The -0.4% here:

goes to https://perf.rust-lang.org/detailed-query.html?commit=ff7f3cf166d39b2bb82d399012ccd2f74e32630d&base_commit=cd64446196a02e593c5f50b8d863161306da43f7&benchmark=packed-simd-doc&run_name=full.

[osa1]

@jyn514 thanks. So there is no way to test #82397 with #82724, at least on CI?

[osa1]

Hm, I guess I could open a PR including both of these PRs, and evaluate that, right?

[jyn514]

Hm, I guess I could open a PR including both of these PRs, and evaluate that, right?

Yes, that's what I meant.