**TL;DR ↵
Scanf/printf is very slow in the GNU C++17 (64) compiler.↵
Use cin/cout with `ios_base::sync_with_stdio(0);cin.tie(0);` or fastio for problems with large io and/or tight TL instead.**↵
↵
So during [contest:1423] a submission ([submission:94787679]) using scanf/printf by one of my friends got TLE in the contest. ↵
After the contest I tried to add fread/fwrite for that submission and got Accepted in 405ms: [submission:94813416].↵
What surprised me is that the same solution can also get Accepted in 577ms ([submission:94878150]) by using cin/cout with `ios_base::sync_with_stdio(0);cin.tie(0);`.↵
↵
There are blogs testing cin/cout vs scanf/printf in the past, like [this one](/blog/entry/57745).↵
Results in that blog probably still holds for those compilers, however the same experiments on the new 64-bit msys2 G++ 9.2.0 complier seem to yield bizarre results: [submission:94881344] using cin/cout runs in 140ms while [submission:94881344] using scanf/printf runs in 404ms.↵
↵
We had detective blogs like [this one](/blog/entry/47180) in the past, so I wonder if anyone has got a clue about what's going on.
Scanf/printf is very slow in the GNU C++17 (64) compiler.↵
Use cin/cout with `ios_base::sync_with_stdio(0);cin.tie(0);` or fastio for problems with large io and/or tight TL instead.**↵
↵
So during [contest:1423] a submission ([submission:94787679]) using scanf/printf by one of my friends got TLE in the contest. ↵
After the contest I tried to add fread/fwrite for that submission and got Accepted in 405ms: [submission:94813416].↵
What surprised me is that the same solution can also get Accepted in 577ms ([submission:94878150]) by using cin/cout with `ios_base::sync_with_stdio(0);cin.tie(0);`.↵
↵
There are blogs testing cin/cout vs scanf/printf in the past, like [this one](/blog/entry/57745).↵
Results in that blog probably still hold
↵
We had detective blogs like [this one](/blog/entry/47180) in the past, so I wonder if anyone has got a clue about what's going on.