Prefer to_string() to format!()

[ljedrz]

Simple benchmarks suggest in some cases it can be faster by even 37%:

test converting_f64_long  ... bench:         339 ns/iter (+/- 199)
test converting_f64_short ... bench:         136 ns/iter (+/- 34)
test converting_i32_long  ... bench:          87 ns/iter (+/- 16)
test converting_i32_short ... bench:          87 ns/iter (+/- 49)
test converting_str       ... bench:          54 ns/iter (+/- 15)
test formatting_f64_long  ... bench:         349 ns/iter (+/- 176)
test formatting_f64_short ... bench:         145 ns/iter (+/- 14)
test formatting_i32_long  ... bench:          98 ns/iter (+/- 14)
test formatting_i32_short ... bench:          93 ns/iter (+/- 15)
test formatting_str       ... bench:          86 ns/iter (+/- 23)

[rust-highfive]

r? @petrochenkov

(rust_highfive has picked a reviewer for you, use r? to override)

[killercup]

Most likely the wrong place to ask this: Can we special-case the format macro for the format!("{}", something) case and expand it to something.to_string() for some known types like &str, String, Cow<str>, and friends? Avoiding this performance trap might be worth the hassle.

[ljedrz]

@killercup the cases you are describing should already be covered by the useless_format clippy lint. I haven't seen one for non-string types implementing Display, but there already seems to be a related issue in the clippy repo.

[killercup]

@ljedrz a lint is not the same as making this macro do "the right thing" automatically. But this is a drive-by comment, at best. I'll look for/open a new issue.

[petrochenkov]

@bors r+

[bors]

📌 Commit 57a5a9b has been approved by petrochenkov

[bors]

⌛ Testing commit 57a5a9b with merge 023fd7e...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: petrochenkov
Pushing 023fd7e to master...