Inline i64tostr and itostr#13840
Conversation
Note to reviewers: This pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
|
utACK e00407dbbd13ccb8fd789811b4fee6871f737f9e |
|
I'm not sure this is a good idea. So tend toward NACK. |
These methods don't give us much, and removing them removes utilstrencodings's dependence on tinyformat
|
I checked for cases in need of optimization and don't really see them. Here are some numbers which show about an order of magnitude of variance: http://www.zverovich.net/2013/09/07/integer-to-string-conversion-in-cplusplus.html fmt seems to have the fastest implementation according to these: http://www.zverovich.net/2013/09/07/integer-to-string-conversion-in-cplusplus.html https://github.com/fmtlib/fmt#speed-tests but I doubt it's worthwhile to bring that in. Looking into that led me to inlining |
|
I'm tending towards a Nack for this too unfort.
When yous say inlining, you mean in the code but the function is inlined anyway so run time it won't have a performance impact. I like the functions since they document the code. It's easier to read :-) |
|
Thanks for the look! Closing due to NACKs. |
These methods don't give us much, and removing them removes utilstrencodings's
dependence on tinyformat