THIS IS VERY UNFAIR!!!

#	User	Rating
1	tourist	3993
2	jiangly	3743
3	orzdevinwang	3707
4	Radewoosh	3627
5	jqdai0815	3620
6	Benq	3564
7	Kevin114514	3443
8	ksun48	3434
9	Rewinding	3397
10	Um_nik	3396

#	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	156
8	TheScrasse	154
9	Dominater069	153
10	nor	152

Today I participated in Codeforces Round 348 (VK Cup 2016 Round 2, Div. 2 Edition), I managed to solve the first three problems in a very good time.

I started with problem D. didn't take long to figure out the idea (I like it very much BTW :). I submitted and got TLE on pretest 11. I knew it was because of huge input so I added

ios_base::sync_with_stdio(0);
cin.tie(0);
cout.tie(0);

I know that with these three lines cin/cout becomes almost as fast as scanf/printf. so I resubmitted the problem and got pretests passed. I have about 40 minutes left so I move to the last problem.

So the system test finishes, and I am shocked that my solution for D got TLE on test 29!!! Although it runs in O(n) complexity!!!

After five long hours of waiting till I can submit again -_- ... I just changed cin/cout to printf/scanf and get ACCEPTED!

problem link: 669D - Little Artem and Dance

TL submission: 17493329

AC submission: 17500406

I don't think there is another unwanted solution with a close running time to this one!! (I believe O(n log n) solution would be fairly slower than O(n) )...

So I wonder why did they use this huge input and this very tight Time Limit??

I just can't imagine I just lost 50 rating for this $#^&!

I DON'T LIKE SCANF/PRINTF AND YOU SHOULDN'T MAKE ME USE THEM!!!

AT LEAST YOU CAN INDICATE THAT YOU ARE A PIECE OF $#^& IN THE PROBLEM STATEMENT SO I REMEMBER TO USE THEM NEXT TIME.

This is not the first time I see this issue, and I am not saying this for the ~200 places I lost for it. but I think problem setters should take extra care when setting the TL to deliver a fair and happy competition to all the users :)

I am wondering if anyone else ever had the same problem? this time or in another round??

I know I did but not in an official round so it didn't matter much!

My suggestions:

either stretch the TL so both solutions pass
or make the input a bit smaller so it won't have this HUGE impact on running time
or write a note at the end of the problem to use scanf/printf
or send an announcement that cin/cout will not be accepted