# Run-time null checks and performance **URL:** \ **Category:** Android\ **Created:** [November 10, 2016, 1:03pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086 "2016-11-10T13:03:10Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![tomjb](https://avatars.discourse-cdn.com/v4/letter/t/76d3ee/32.png) [@tomjb](https://discuss.kotlinlang.org/u/tomjb)\ **Post date:** [November 10, 2016, 1:03pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/1 "2016-11-10T13:03:10Z")
Non-nullable parameters (of functions visible to Java code) are null-checked at run time via calls to `Intrinsics.checkParameterIsNotNull`. For example, every time the following function is called, there will be three calls to `Intrinsics.checkParameterIsNotNull`: ``` fun foo(first: String, second: String, third: String) {} ``` If we call `foo` 100 times in a loop, `Intrinsics.checkParameterIsNotNull` will be called 300 times. This seems wasteful, and I wonder how this performs on Android (where I don’t know whether inlining will take place). As stated [here](http://stackoverflow.com/a/31723265), it’s possible to avoid generating these calls with `-Xno-param-assertions` and `-Xno-call-assertions`, but these options are unsupported and could be removed. Could these flags be supported? Or could Intrinsics.checkParameterIsNotNull perhaps be marked `inline`? I feel like this is an important topic that isn’t being taken seriously on Android. Note that optimizing these calls away using ProGuard is not necessarily a good solution, as using ProGuard optimization [isn’t strongly recommended](https://android.googlesource.com/platform/sdk/+/master/files/proguard-android-optimize.txt) on Android. ---
**Author:** ![mplatvoet](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/mplatvoet/32/7121_2.png) [@mplatvoet](https://discuss.kotlinlang.org/u/mplatvoet)\ **Post date:** [November 10, 2016, 1:09pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/2 "2016-11-10T13:09:43Z")
You really try the raise awareness, don’t you 😉 > [@Performance: Intrinsics.checkNotNull called for every parameter](https://discuss.kotlinlang.org/t/performance-intrinsics-checknotnull-called-for-every-parameter/1971): > > As far as I can tell, every non-nullable reference-type parameter of every non-private method is null-checked at run time (with a call to the static method kotlin.jvm.internal.Intrinsics.checkNotNull). In particular, the two-parameter method is called. I’m not at the computer right now, and I’m going on memory, so please correct me if I’m wrong. If I’m right, does anyone know whether this could entail performance problems on Android? The following document, for example, is quite strict about w… ---
**Author:** ![tomjb](https://avatars.discourse-cdn.com/v4/letter/t/76d3ee/32.png) [@tomjb](https://discuss.kotlinlang.org/u/tomjb)\ **Post date:** [November 10, 2016, 1:23pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/3 "2016-11-10T13:23:00Z")
I considered replying to that topic instead of creating this one, but that that topic ended up losing focus a little. I added extra information to this topic, so it’s not like I’m simply posting the same thing here. All in all, I hope JetBrains replies, because I feel that this is an imporant issue. And Kotlin does advertise itself as “for the JVM, Android and the browser” — a lot of people believe that Kotlin supports Android as a first-class citizen. Furthermore, any optimizations the JVM does are irrelevant and not helpful for Android. ---
**Author:** ![yole](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/yole/32/1425_2.png) [@yole](https://discuss.kotlinlang.org/u/yole)\ **Post date:** [November 10, 2016, 1:40pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/4 "2016-11-10T13:40:20Z")
Do you have any specific evidence that those not-null checks affect performance in real Android code, or are you asking us to make these compiler parameters officially supported based on a general feeling that these checks might possibly affect performance? ---
**Author:** ![tomjb](https://avatars.discourse-cdn.com/v4/letter/t/76d3ee/32.png) [@tomjb](https://discuss.kotlinlang.org/u/tomjb)\ **Post date:** [November 10, 2016, 2:15pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/5 "2016-11-10T14:15:21Z")
Sorry, I don’t have evidence. I’m not an expert at performance testing on Android, and as far as I know it’s very hard to get this right. I just think this has enough potential to be a problem that it should be possible to switch it off. I can imagine telling any expert Android programmer “I’m going to insert a harmless function call every time you pass a reference to a non-private method” and listening to them asking about performance thereafter. I also think this behaviour will surprise a lot of people. I wonder how many Kotlin programmers know that, for example, changing a five-parameter function from private to public adds five `Intrinsics.checkParameterIsNotNull` calls to the generated bytecode (if those five parameters are non-nullable references). Thanks for your reply. ---
**Author:** ![voddan](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/voddan/32/1673_2.png) [@voddan](https://discuss.kotlinlang.org/u/voddan)\ **Post date:** [November 12, 2016, 12:05pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/6 "2016-11-12T12:05:31Z")
As far as I know, JVM adds those null checks anyway to fulfill its specification. So in fact, adding those null assertions on the Kotlin side should speed up it a little, not slow down. Besides, elimination of null assertions is one of the most basic and common optimisations on JVMs (Android or not), so theoretically there is nothing to worry about. But this is all theory. To reason about the performance impact of this case one needs at least micro benchmarks. Otherwise this is all just chat. If you are going to do them, please make sure you use JMH, and later publish the code of the benchmarks. ---
**Author:** ![tomjb](https://avatars.discourse-cdn.com/v4/letter/t/76d3ee/32.png) [@tomjb](https://discuss.kotlinlang.org/u/tomjb)\ **Post date:** [November 12, 2016, 6:22pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/7 "2016-11-12T18:22:28Z")
I don’t believe that null checks are relevant here, as my concern is about the calls to the method, not the null check inside that method. ---
**Author:** ![yole](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/yole/32/1425_2.png) [@yole](https://discuss.kotlinlang.org/u/yole)\ **Post date:** [November 12, 2016, 6:49pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/8 "2016-11-12T18:49:09Z")
If only JMH ran on Android… ---
**Author:** ![tomjb](https://avatars.discourse-cdn.com/v4/letter/t/76d3ee/32.png) [@tomjb](https://discuss.kotlinlang.org/u/tomjb)\ **Post date:** [November 12, 2016, 8:13pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/9 "2016-11-12T20:13:05Z")
Thinking about this again – I wonder about the idea of rewriting Intrinsics.checkParameterIsNotNull in Kotlin and adding the `inline` keyword. If feasible, this seems like a sensible idea. ---
**Author:** ![tomjb](https://avatars.discourse-cdn.com/v4/letter/t/76d3ee/32.png) [@tomjb](https://discuss.kotlinlang.org/u/tomjb)\ **Post date:** [November 13, 2016, 3:06pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/11 "2016-11-13T15:06:44Z")
I don’t see how that Wikipedia page is relevant to this topic. ‘Intrinsics’ is just a class name that JetBrains decided to use. They could have called it almost anything. You can verify that the Kotlin compiler is generating bytecode for calling Intrinsics.checkParameterIsNotNull by using `javap` on the generated ‘.class’ files. ---
**Author:** ![tomjb](https://avatars.discourse-cdn.com/v4/letter/t/76d3ee/32.png) [@tomjb](https://discuss.kotlinlang.org/u/tomjb)\ **Post date:** [May 17, 2017, 11:48pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/12 "2017-05-17T23:48:32Z")
Google today announced official support for Kotlin for Android development, and I saw this in their FAQ ([FAQ Kotlin di Android  |  Android Developers](https://developer.android.com/kotlin/faq.html)): > [@](#): > > calling a method that accepts non-null types adds a method call for the null check (though you can disable runtime null checks in the compiler with -Xno-param-assertions). Can I take this to mean that `-Xno-param-assertions` is guaranteed to be supported in future? ---
**Author:** ![yole](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/yole/32/1425_2.png) [@yole](https://discuss.kotlinlang.org/u/yole)\ **Post date:** [May 18, 2017, 7:58am UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/13 "2017-05-18T07:58:06Z")
I’m not aware of any discussions between JetBrains and Google regarding this particular option, or of any commitments from our side that would require us to keep the compatibility of advanced compiler options. ---
**Author:** ![tomjb](https://avatars.discourse-cdn.com/v4/letter/t/76d3ee/32.png) [@tomjb](https://discuss.kotlinlang.org/u/tomjb)\ **Post date:** [May 18, 2017, 1:21pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/14 "2017-05-18T13:21:31Z")
In my view, it would be a good idea for this compiler flag to be officially supported, for at least the Android use case. Although I don’t have benchmarks here, it looks like Google finds this feature important enough to mention in their Kotlin FAQ. Google could have easily left this detail out – in fact, their FAQ isn’t very long – but they clearly felt it worth addressing. ---
**Author:** ![yole](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/yole/32/1425_2.png) [@yole](https://discuss.kotlinlang.org/u/yole)\ **Post date:** [May 18, 2017, 3:50pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/15 "2017-05-18T15:50:20Z")
Well, we have no plans to drop this feature either. To make a decision on official support, benchmarks would be essential. ---
**Author:** ![fab1an](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/fab1an/32/1934_2.png) [@fab1an](https://discuss.kotlinlang.org/u/fab1an)\ **Post date:** [June 26, 2017, 1:06pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/16 "2017-06-26T13:06:55Z")
When working on some high-performance algorithms. I didn’t found `checkNotNull` to be an issue, but I had some other gotchas which cost me at times 5-10% performance according to JMH: - `when` uses `Intrinsics.areEquals` sometimes, when a reference comparison would suffice: [https://youtrack.jetbrains.com/issue/KT-18435](https://youtrack.jetbrains.com/issue/KT-18435) - comparing an `Int` with an `Int?` or passing it to a method with an nullable parameter invokes `Integer.valueOf` - Same thing seems to be the case when using a primitive type as generic parameter, though I didn’t find much of an performance impact in that case. - Equality-comparison of an Enum value `if (myVal == MyEnum.ASDF) ...` invokes `Intrinsics.areEquals` where a reference comparison would suffice. A word of advice to the OP: If you care about performance, I would first check my code for allocations in hot codepaths, like `Iterator` allocations in `.forEach` et. al. In hot methods I substituted `forEach` with the following method. (Beware that it won’t tell you about concurrent modifications!) ```auto inline fun List.forEachNoAlloc(block: (T) -> Unit) { var idx = 0 while (idx < size) { block(this[idx]) idx++ } } ``` ---
**Author:** ![elizarov](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/elizarov/32/2164_2.png) [@elizarov](https://discuss.kotlinlang.org/u/elizarov)\ **Post date:** [June 26, 2017, 7:40pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/17 "2017-06-26T19:40:34Z")
You should file YT tockets for other things, too ---
**Author:** ![fab1an](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/fab1an/32/1934_2.png) [@fab1an](https://discuss.kotlinlang.org/u/fab1an)\ **Post date:** [July 1, 2017, 6:14am UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/18 "2017-07-01T06:14:30Z")
- [https://youtrack.jetbrains.com/issue/KT-18435](https://youtrack.jetbrains.com/issue/KT-18435) - [https://youtrack.jetbrains.com/issue/KT-18731](https://youtrack.jetbrains.com/issue/KT-18731) - [https://youtrack.jetbrains.com/issue/KT-18766](https://youtrack.jetbrains.com/issue/KT-18766) ---
**Author:** ![Xerus](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/xerus/32/4499_2.png) [@Xerus](https://discuss.kotlinlang.org/u/Xerus)\ **Post date:** [March 27, 2018, 8:24pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/19 "2018-03-27T20:24:18Z")
I have evidence of it impacting performance: ![image](https://us1.discourse-cdn.com/flex019/uploads/kotlinlang/original/2X/6/6994c8ed0ec85951111d1962728a4dcc1e6ff778.png) adding -Xno-param-assertions and -Xno-call-assertions to the Kotlin compiler options solved it though ---
**Author:** ![mleclair](https://avatars.discourse-cdn.com/v4/letter/m/2bfe46/32.png) [@mleclair](https://discuss.kotlinlang.org/u/mleclair)\ **Post date:** [March 9, 2021, 10:43pm UTC](https://discuss.kotlinlang.org/t/run-time-null-checks-and-performance/2086/20 "2021-03-09T22:43:19Z")
We’ve also noticed a performance issue with the `kotlin.jvm.internal.Intrinsics` class. Our problem was noticed on android application start-up. We’ve decided to open an issue here: [https://youtrack.jetbrains.com/issue/KT-45387](https://youtrack.jetbrains.com/issue/KT-45387)