| # | User | Rating |
|---|---|---|
| 1 | ecnerwala | 3648 |
| 2 | Benq | 3580 |
| 3 | orzdevinwang | 3570 |
| 4 | cnnfls_csy | 3569 |
| 5 | Geothermal | 3568 |
| 6 | tourist | 3565 |
| 7 | maroonrk | 3530 |
| 8 | Radewoosh | 3520 |
| 9 | Um_nik | 3481 |
| 10 | jiangly | 3467 |
| # | User | Contrib. |
|---|---|---|
| 1 | maomao90 | 174 |
| 2 | adamant | 164 |
| 2 | awoo | 164 |
| 4 | TheScrasse | 160 |
| 5 | nor | 159 |
| 6 | maroonrk | 156 |
| 7 | -is-this-fft- | 150 |
| 8 | SecondThread | 147 |
| 9 | orz | 146 |
| 10 | pajenegod | 145 |
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.