Please read the new rule regarding the restriction on the use of AI tools. ×

Is scanf/printf ever too slow?
Difference between en1 and en2, changed 17 character(s)
Usually, I hear people saying that `std::cin` and `std::cout` is a relatively slow form of input while `scanf` and `printf` is a faster form of input which should be sufficient for all problems. However, sometimes I wonder if there are any problems where `scanf` and `printf` would be too slow.↵

For example, look at the problem [1181D — Irrigation](https://codeforces.net/contest/1181/problem/D). This problem asks us to read in 500,000 numbers, each of which could be as large as 500,000, and then asks us to read in 500,000 more numbers, each of which could be as large as $10^{18}$. Clearly, this is a lot of input/output, so users should use `scanf` and `printf` over `std::cin` and `std::cout`. However, even when I used `scanf` and `printf`, [my solution](https://codeforces.net/contest/1181/submission/56247817) ran in 2355 ms, barely under the time limit of 2.5 seconds. 
ThenOn the other hand, when I rewrote my code using an I/O library I wrote myself, which uses `fread` and `fwrite` to read/write 32768 bytes at a time, [my improved solution](https://codeforces.net/contest/1181/submission/56247773) ran in 592 ms, almost 4 times faster than the original solution.↵

Since my code barely ran under time using `scanf` and `printf`, I wonder if there are any CodeForces problems where using `scanf` and `printf` will inevitably lead to a Time Limit Exceeded error and users must use some other I/O method like I did. Has anyone else encountered a problem where `scanf` and `printf` just weren't quite fast enough? Moreover, has anyone else built a custom I/O library for competitive programming like I did? If anyone has knows how to do input/output faster than `fread` and `fwrite`, I would love to hear about it.

History

 
 
 
 
Revisions
 
 
  Rev. Lang. By When Δ Comment
en2 English Noble_Mushtak 2019-06-29 02:21:40 17 fixed erroneous detail
en1 English Noble_Mushtak 2019-06-29 02:20:04 1746 Initial revision (published)