ORIGINAL:

During the contest this morning I had issues with my code TLEing on 1827A - Counting Orders. I was using Kotlin's built-in functions for IO which in the past has worked fine for A's constraints, but this time I got TLE until I resubmitted using a FastScanner. I've had issues like this in a couple of recent contests too, and today I figured out the cause.

This is my first submission from the contest (in Kotlin 1.7), which got TLE on pretest 4: 205850184

This is a resubmission of the identical code just now to make sure CF's issues at the beginning of the contest didn't affect the timing (still TLE test 4): 205929004

This is a resubmission of the same identical code in Kotlin 1.6, which passed in 623 ms: 205929005

So apparently there's a huge difference in the speed of Kotlin IO between versions 1.6 and 1.7. This difference seems to specifically be in Kotlin's input function (readLine), because making the output faster didn't appreciably change the runtime of the AC submission (using StringBuilder, 639 ms: 205928985).

Not sure how many people use Kotlin, but if you do and didn't already know this then this is a good thing to keep in mind (though many people probably use FastScanner anyway).

UPDATE:

Submissions using FastScanner:

Kotlin 1.7 (TLE on tc 7): 205929602 Kotlin 1.6 (390 ms): 205929613

Something is very slow in Kotlin 1.7, but it's not (just) the builtin IO like I thought before.