| # | User | Rating |
|---|---|---|
| 1 | tourist | 4009 |
| 2 | jiangly | 3823 |
| 3 | Benq | 3738 |
| 4 | Radewoosh | 3633 |
| 5 | jqdai0815 | 3620 |
| 6 | orzdevinwang | 3529 |
| 7 | ecnerwala | 3446 |
| 8 | Um_nik | 3396 |
| 9 | ksun48 | 3390 |
| 10 | gamegame | 3386 |
| # | User | Contrib. |
|---|---|---|
| 1 | cry | 167 |
| 2 | Um_nik | 163 |
| 3 | maomao90 | 162 |
| 3 | atcoder_official | 162 |
| 5 | adamant | 159 |
| 6 | -is-this-fft- | 158 |
| 7 | awoo | 157 |
| 8 | TheScrasse | 154 |
| 9 | Dominater069 | 153 |
| 9 | nor | 153 |
I solved this problem in CF #705. 
But it failed system testing showing 
If we compare this two submissions-
This is the only difference.
The main thing is I used cerr for debugging and it got TLE.
Can anyone explain Why did it happen?
Great
Nothing is absolutely free. Your debugging print code consumes precious CPU cycles.
If I recall correctly, on some online judges
cerris sent to/dev/null, and "writing" there is very fast. Sadly, not on Codeforces.Even if cerr is redirected to /dev/null, the useless output strings are still being created in huge amounts. The blog author's main loop contains only a tiny amount of arithmetic operations. But each of these loop iterations also tries to at least create one useless std::string and print it to cerr with a ton of overhead.
The failing testcase prints 211.5k lines to stderr and 100 lines to stdout. But I agree that this shouldn't have been fatal. On my computer it takes just slightly more than one second to run if I redirect stderr to /dev/null. And my computer is slower than the codeforces judge.
It's safer to put the debugging print code inside of an
#ifndef ONLINE_JUDGEblock either way.This is why some people define a macro with a local flag instead of a function for debugging: if the local flag is not defined, then the macro will become nothing, and nothing will be run.
Very evil. Accepted: 117533891. Idleness limit exceeded: 117532620. It's not even an interactive problem.