| # | User | Rating |
|---|---|---|
| 1 | tourist | 3985 |
| 2 | jiangly | 3814 |
| 3 | jqdai0815 | 3682 |
| 4 | Benq | 3529 |
| 5 | orzdevinwang | 3526 |
| 6 | ksun48 | 3517 |
| 7 | Radewoosh | 3410 |
| 8 | hos.lyric | 3399 |
| 9 | ecnerwala | 3392 |
| 9 | Um_nik | 3392 |
| # | User | Contrib. |
|---|---|---|
| 1 | cry | 169 |
| 2 | maomao90 | 162 |
| 2 | Um_nik | 162 |
| 4 | atcoder_official | 161 |
| 5 | djm03178 | 158 |
| 6 | -is-this-fft- | 157 |
| 7 | adamant | 155 |
| 8 | awoo | 154 |
| 8 | Dominater069 | 154 |
| 10 | luogu_official | 150 |
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.