Tlatoani's blog

(something in) Kotlin significantly slower in 1.7
By Tlatoani, history, 12 months ago, In English

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. 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.

  • Vote: I like it
  • +97
  • Vote: I do not like it

»
12 months ago, # |
← Rev. 2   Vote: I like it +52 Vote: I do not like it

I had the same issue. I just ended up using 1.6 without switching.

I have known that kotlin 1.7 is slower than kotlin 1.6 by almost 2 times for a long time now — like almost all code. I have been always using FastScanners. I have almost never submitted in kotlin 1.7 for this reason.

In your particular case though, I think it is the List and the Sort that is slow. My submission 206087216 is 592ms on 1.7 (still slow, but passable under the constraints), this is 296ms on 1.6.

The only time I would submit in kotlin 1.7 is when the problem is 64-bits multiplication/division heavy (e.g. calculating mod 998244353), or when I need to take advantage of 64-bits bitset. In that case, kotlin 1.7 seems to be about twice as fast. Therefore, I am still glad to have kotlin 1.7 as an option.

I never understood why is 1.7 considerably slower (I assume it is due to 64bits). I just hope codeforces knows to not to remove kotlin 1.6 before fixing this.

→ Reply