Hacker News Reader

Comment by taspeotis | Hacker News Reader

When I did competitive programming in C++ nobody used fstream for reading input because it was much slower compared to fscanf.

View on HN

It always surprises me how slow streams are. fscanf should be relatively slow because it has to parse the format string at runtime. So the new C++ format should be (and I believe is) much faster

Parsing a string is significantly faster than disk io, so this is not an issue unless you are reading minuscule amounts of data.

That was once true, but not on most modern systems with SSDs. Cheap NVMe SSDs can sustain over 1 GB/s, which only a highly optimized SIMD parsing library can exceed.

You are missing the point. The format string is tens of bytes, parsing it is fast no matter what compared to reading large amounts of data.

Ah, I thought you meant the speed of parsing the payload didn't matter (scanf performance was also discussed). Yes, parsing the format string in printf or scanf isn't a big deal.

I believe the Abseil library has formatting functions that's capable of parsing the format string at compile time.

fscanf() is also pretty slow because of thread safety so each call involves a mutex (which goes unused 99% of the time). I wonder do the new C++ libraries have faster non-threadsafe options?

Does it matter?

The little I did competitive programming, input parsing time was negligible compared to the allowed runtime for solving the problem. Inputs were designed so that if you had the right algorithm, you could do it easily even with terrible optimization. Fast code could be an advantage in the algorithm (but not in parsing), as it could help you "cheat" and, for example, do a problem designed for N² in N³. Personally, I used iostreams, just because I found it a bit easier to type.

But then, different competition have different rules, and maybe there are some where fscanf really is an advantage.

Reply on news.ycombinator.com