Rust: format_args! is slow

[workingjubilee]

Like molasses in the Antarctic.

As a consequence, so is any method which depends on its Arguments, like {fmt, io}::Write::write_fmt. The microbenchmarks in this issue about write!'s speed demonstrate that merely running the same arguments through format_args! and then write_fmt, even if it's just a plain string literal without any formatting required, produces a massive slowdown next to just feeding the same through fmt::Write::write_str or io::Write::write_all.

Unfortunately, write!, format!, println!, and other such macros are a common feature of fluent Rust code. Rust promises a lot of zero-cost abstractions, and on a scale from "even better than you could handwrite the asm" to "technically, booting an entire virtual machine is zero cost if you define the expression as booting a virtual machine..." this is currently "not very". Validating and formatting strings correctly can be surprisingly complex, which is going to increase with features like implicit named arguments in format_args!, so we can expect increasing speed here may be challenging. However, this should be possible, even if it might require extensive redesign.

Multiple Problems, Multiple Solutions

• format_args!'s internal machinery in the Rust compiler can likely be improved.
• Consumers of Arguments, such as fmt::{format, write} and {fmt, io}::Write::write_fmt, can be reviewed for runtime performance.
• Macros downstream of format_args! often are invoked to do something simple that does not require extensive formatting and can use the pattern-matching feature of macro_rules! to special-case simple patterns to side-step format_args! when it's not needed. This will increase the complexity of those macros and risks breakage if done incautiously, but could be a big gain in itself.

Unfortunately some of these cases may run up against complex situations with types, trait bounds, and method resolutions, because e.g. both io::Write and fmt::Write both exist and write! needs to "serve" both. Fortunately, this is exactly the sort of thing that can benefit from the recent advances in const generics, since it's a lot of compile-time evaluation that could benefit from interacting with types (as opposed to being purely syntactic like macros), and in the future generic associated types and specialization may be able to minimize breakage from type issues as those features come online, so it's a good time to begin reviewing this code.

Related issues and PRs

• #75742 (and #75894)
• #75301 (and #75358)
• #52804
• #10761

[Mark-Simulacrum]

Note that the formatting infrastructure in core::fmt is intentionally not fast, as it optimizes for code size over speed. There are alternatives, e.g., https://github.com/japaric/ufmt which is smaller/faster and makes some different tradeoffs.

I don't know that a blanket issue like this is useful -- I suspect the overall API cannot change at this point, but individual improvements can be, of course, discussed in T-compiler (as this is a libs impl, not T-libs, concern).

[jonas-schievink]

It's code size is also notoriously poor for embedded systems fwiw

[Mark-Simulacrum]

It's true that it may not meet the code size goal well either - I do think we should try and go for size over speed in general, though the two are not always mutually exclusive.

[workingjubilee]

Are there other alternatives like ufmt primarily for embedded use?
Size is cache and cache is speed, or rather the not needing it. It is _probably_ the case that many optimizations for speed will help reduce overall size as well (and vice versa), and Arguments itself is sequestered from instantiation or introspection and versioned internally. It's not as obscured as a nameless type, but it is likely easy to change many subtle particulars about it without breaking major APIs.

Other crates of interest:

• https://github.com/dtolnay/itoa
• https://github.com/dtolnay/dtoa

[jonas-schievink]

Are there other alternatives like ufmt primarily for embedded use?

We've also recently written https://github.com/knurling-rs/defmt, which does the formatting on the host instead of the device through liberal use of the forbidden arts. It is not compatible with the core::fmt syntax though, and can only be used for logging (since the device can't actually use the formatted data).