-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimizing runtime performance for the literal string case #39
Comments
parse-display/parse-display-derive/src/lib.rs Lines 1079 to 1085 in 6134916
Currently, enum FormatPart {
Str(String),
Placeholder {
format_specifier: String,
expr : Expr,
}
} I would like to make this change in the future if the performance impact is significant. |
Thanks! I made a similar suggestion in dtolnay/thiserror#285 and the pending pull request in dtolnay/thiserror#286 . You can see the assembly difference here Profiling would be fairly tricky though, as it would have to have some sort of a re-usable buffer whose allocation would not impact the profiling results. It does sound the code here is much more involved than in the |
P.S. Note that there an another optimizations added to |
Thanks for the info.
Since I also did some benchmarking and it seems to make quite a difference. before:
after:
|
Rust compiler at present is unable to generate as efficient code for
write!(f, "string")
as it can do forf.write_str("string")
. I tried to look through the code, but it seems fairly complex in how you generate the output token stream. Would it be possible to handle the case when the string is known ahead of time and does not contain either{
or}
characters, and use thewrite_str
instead?The text was updated successfully, but these errors were encountered: