Rewrite fmt! for performance #3571
Labels
A-frontend
Area: Compiler frontend (errors, parsing and HIR)
I-slow
Issue: Problems and improvements with respect to performance of generated code.
Comments
|
It should also probably use traits to work with more types, per #1653 |
Merged
bors
added a commit
that referenced
this issue
Mar 22, 2013
This is a minor step towards #3571, although I'm sure there's still more work to be done. Previously, `fmt!` collected a bunch of strings in a vector and then called `str::concat`. This changes the behavior by maintaining only one buffer and appending directly into that buffer. This avoids doubly-allocating memory, and it has the added bonus of reducing some allocations in `core::unstable::extfmt` One of the unfortunate side effects of this is that the `rt` module in `extfmt.rs` had to be duplicated to avoid `stage0` errors. Dealing with the change in conversion functions may require a bit of a dance when a snapshot happens, but I think it's doable. If the second speedup commit isn't deemed necessary, I got about a 15% speedup with just the first patch which doesn't require any modification of `extfmt.rs`, so no snapshot weirdness. Here's some other things I ran into when looking at `fmt!`: * I don't think that #2249 is relevant any more except for maybe removing one of `%i` or `%d` * I'm not sure what was in mind for using traits with #3571, but I thought that formatters like `%u` could invoke the `to_uint()` method on the `NumCast` trait, but I ran into some problems like those in #5462 I'm having trouble thinking of other wins for `fmt!`, but if there's some suggestions I'd be more than willing to look into if they'd work out or not.
|
Not critical for 0.6, de-milestoning |
|
This doesn't seem to have been nominated, but had a milestone attached. Does this really need to be on production-ready? Is fmt! usually a huge performance bottleneck? Re-nominating so we can discuss. |
|
accepted for backwards-compatible milestone |
|
This is currently underway with the new |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
fmtwas written in the stone ages and is not fast. It should be rewritten to use either anio::Writeror some kind of string builder, and it should use stack allocation everywhere it can. It should not emit lots of inline code to bloat up function bodies, instead delegating tocore::extfmtfunctions marked with#[inline], leaving the amount of inlining up to LLVM.The text was updated successfully, but these errors were encountered: