Kotlin JS performance

I’ve been complaining about the KotlinJS performance from the very beginning, and I’m sorry, but I have to be a squeaky wheel until it gets resolved.

https://youtrack.jetbrains.com/issue/KT-24784

image

I want a way to compile the JS side without type checking.
Anywhere I have code like this:

    override fun equals(other: Any?): Boolean {
		if (this === other) return true
		other as Matrix4Ro

Causes huge slowdowns. 99% of my frame is eaten up by type checking, and the only way for me to work around the problem is monkey patching kotlin, which has been fragile when updating.

For production code, any place that generates the following:

Kotlin.isType(tmp$ = other, Matrix4Ro) ? tmp$ : throwCCE();

I want completely stripped in production code. Class cast exceptions are only useful for debugging and they absolutely kill performance in the browser.

Please give this squeaky wheel some grease. Kotlin will be 100x faster in the browser if this is resolved.

3 Likes

Have you tried TeaVM compiler in order to compare performance ?
Or GWT, yes I know it can not Kotlin, but it is possible to write equivalent code to compare performance.

I haven’t tried TeaVM. It looks very tempting, but if I can help it I’d prefer to stay on the official JetBrains compiler.
I’ve had good luck in the past with GWT performance, but the workflow and debugging is garbage.
The Kotlin to JS performance is bad only because of type checking. If I run my monkey patcher and strip out type checks that only result in class cast exceptions performance is OK.
I’d much rather convince JetBrains to have a production flag for the compiler that sacrifices debugability for performance. Especially considering that 90% of the problem is just in these type checks, which the pre-1.0 versions of Kotlin didn’t even have. I am hoping to have a WebASM version in the future, but that won’t work in IE 11, which is the browser that has the worst performance that I’m trying to actually support.

I may give TeaVM a try soon; it’s the second time JetBrains has suggested it in response to my performance complaints. This is very strange to me, I would think that JetBrains would be committed to making a performant JS transpiler.

1 Like

This is my personal suggestion to better understand what other systems do in the same situaton.

Regardless removal typechecking, It can not be simply removed since the language specs enforce it.

Regardless removal typechecking, It can not be simply removed since the language specs enforce it

I understand why you are saying this, but I believe you are not thinking about this from a product perspective. Right now Kotlin is unusable in production for JavaScript without monkey patching because it is so slow. I am not exaggerating when I say that Kotlin produces code that is 100x slower than hand written javascript.
Even when simply retrieving a value out of a List, that type check will topple an application.
I’m not proposing removing type checking, I’m proposing removing type checking A) Only in production code, and B) Only in places where the result of a failed type check is just an error.

The reason that’s safe is because the compiler prevents you from incorrectly using types, you don’t need the runtime to tell you what you already know.
A List ensuring that the value returned is the correct type and throwing an error if it’s not? That’s useless, the code wouldn’t compile if you tried to put an incorrect type in that List in the first place.

1 Like

Comparing to GWT is a good way to see how far Kotlin JS is behind in terms of file size and performance. GWT doesn’t seem to do any runtime type checking.
However, I don’t wish to switch to GWT because as I said before, their workflow is terrible. Kotlin has the ability to set a breakpoint in the kotlin code and hit that breakpoint in Chrome. As far as workflow goes Kotlin is better than GWT, Dart, or TypeScript.
TeaVM might be a good option to try.

1 Like