Hacker News Reader

Comment by vitaut | Hacker News Reader

The new benchmark is even less meaningful because

1. It now constructs unnecessary `std::string` penalizing `format_int`:

value+=fmt::format_int(i).str().size();

2. The input is consecutive numbers which makes branches well predicted which is not realistic but beneficial for fast_io integer formatter which has a lot of branches.

The precomputed table you can find in include/fast_io_core_impl/integers/jiaendu/table_gen.h

View on HN

> 1. It now constructs unnecessary `std::string` penalizing `format_int`: > value+=fmt::format_int(i).str().size();

Author appears to be doing the equivalent in the other benchmark:

value+=fast_io::to<std::string>(i).size();

Maybe you could argue that in both cases it would be better not to measure time spent creating and destroying strings, but I don't see how the two benchmarks are not comparable.

If std::string construction was the goal then sure, but that's not what the original benchmark that I've written was about. The goal was to find the fastest way to format an integer with or without std::string construction: http://www.zverovich.net/2013/09/07/integer-to-string-conver.... Those methods that construct a string but not required to are explicitly marked. The OP made some claims based on the method that doesn't construct std::string (which is one of the reasons it's rather fast) and then when I pointed out that it's unsafe switched to a much slower one but at the same time unnecessarily penalized other methods. It seems like moving a goalpost just to prove that your method is the fastest (which might be true but we don't know because of a poor methodology).

Reply on news.ycombinator.com