fmt! could be optimized for some combinations of arguments

[Kimundi]

There are at least two cases where fmt! could perform an early optimization:

• fmt!("...") could expand to the same code as an ~"..." string literal.
• fmt!("%s", s) could expand to s

Both optimizations seem unnecessary on their own (why call fmt! at all?), but might be useful considering that certain core macros use fmt! internally.

[catamorphism]

(bug triage) Not a blocker, IMO, without knowing what the performance savings would be.

[alexcrichton]

With the new ifmt! extension, I'm getting the following numbers

extern mod extra;

#[inline(never)]
fn used(_: ~str) {}

#[bench]
fn vanilla(b: &mut extra::test::BenchHarness) {
    do b.iter {
        let a = ~"test";
        used(a)
    }
}
#[bench]
fn ifmt_no_args(b: &mut extra::test::BenchHarness) {
    do b.iter {
        let a = ifmt!("test");
        used(a)
    }
}
#[bench]
fn ifmt_one_arg(b: &mut extra::test::BenchHarness) {
    do b.iter {
        let a = ifmt!("{:s}", "test");
        used(a)
    }
}

running 3 tests
test ifmt_no_args ... bench: 95 ns/iter (+/- 1)
test ifmt_one_arg ... bench: 108 ns/iter (+/- 3)
test vanilla ... bench: 75 ns/iter (+/- 2)

test result: ok. 0 passed; 0 failed; 0 ignored; 3 measured

Which basically reflects what you would expect. I'm not sure that this is a common enough occurrence to warrant the extra code to deal with it, but this at least shows what the performance characteristics would look like.

[alexcrichton]

With the movement to format, optimizations and speed has been earned elsewhere by reducing code bloat and allocations.

While still a possible optimization, I'm going to close this for now because I'm not sure that this is entirely possible with trait-based formatting as opposed to statically knowing what types of what's being formatted.

In the future though, if this does indeed turn up to be a problem, we can certainly investigate ways to optimize it.