Speed up fmt! by 20%

[alexcrichton]

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 Finish the polish on format! #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 Rewrite fmt! for performance #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 Integer type inference confusion #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.

[pcwalton]

The biggest win for fmt! is just going to be to add functions that also write directly to io::Writers instead of building up intermediate strings.

[bstrie]

What's the purpose of this function? I'm not seeing it called from anywhere.

[alexcrichton]

Oh whoops, I added that in for a previous scheme I was doing, but you're right that it's no longer necessary so I'll remove it.

[alexcrichton]

I tried to do something like that by passing the string buffer to as many functions as possible, but to account for things like padding and numbers being generated from right-to-left, I'm not sure how many more intermediate strings can be eliminated.

Right now the only intermediate string is actually when formatting numbers, and I found it difficult to change that because of the way the numbers are generated, and then also having to deal with padding. For other things, strings always have to copy memory, bools copy from static memory, and poly conversions have the same problem as numbers where to do padding the intermediate form is necessary.

One thing I can try is a sort of "fast path" for conversions which don't have any padding, because those can mostly just be emitted directly into the string buffer. That would probably require a lot of changes though, so I'll open another pull request later with that if this goes through.

[pcwalton]

Sure, that's fine if some things have to build intermediate strings (although it might be nice to have a SmallString optimization so that small strings can be stored on the stack and only spill to the heap if necessary). What I was referring to is that instead of building up a buffer the extfmt functions should take an &io::Writer.

[alexcrichton]

Oh I thought it was only possible to create @ instances of traits to pass around, I'm not even aware of how it's possible to create an &io::Writer

I just tried doing something like

fn foo(a: &'b io::Writer) {      
}                                

fn bar(b: &'b io::BytesWriter) { 
  foo(b as &'b io::Writer);      
}                                

fn main() {                      
}                                

But I got an ICE from it. Is there a way to create traits as borrowed pointers?

[catamorphism]

@alexcrichton The intent is that it should be possible, but currently there are some open issues about objects with storage other than @.

[alexcrichton]

Oh ok, I'll try to keep an eye out for when that comes around and see if this can be modified a bit. I know that conv_poly would benefit immediately from passing an io::Writer instance instead of using a string buffer, and perhaps numbers could be worked on as well. Thanks for the clarification!

[bstrie]

Has bors already been over this pull request twice? If there are still changes yet to be merged, I think it would be better to rebase and open a new pull request rather than continue pushing new commits to this one. I'm honestly not sure if bors is smart enough to understand the latter.

[alexcrichton]

Bors takes care of this just fine as far as I can tell. I just takes this series of commits (whatever is current) and plants it on top of incoming, naming the result 'auto'. I've had a couple pull requests in the past which you just have to continually rebase to keep up with merge conflicts.

In this case, bors dealt with it twice, but both had build failures (which should be fixed now). This should be ready for another go at this point.

[alexcrichton]

Fourth time's the charm, right?