But what about when it comes to runtime? Is there an appreciable hit operationally?

# announcements

[Hullaballoonatic]

But what about when it comes to runtime? Is there an appreciable hit operationally?

[gildor]

I don’t think so, just a number of methods, virtual method lookup probably the same, but not exactly sure

[Hullaballoonatic]

Is class comparison more expensive than property accessing?

interface Bar

class Foo(val isBar: Boolean = true) : Bar

val foo = Foo()

println(foo is Bar)
// vs
println(foo.isBar)

[gildor]

There is no class comparison, but instanceof check

[gildor]

I don’t know what is faster, but both are very fast (instanceof is just bytecode instruction, property access is just instance member call)

[gildor]

using special field just for instance check is very strange

[Hullaballoonatic]

Okay thanks, and yeah, sorry about the mixup. I use class checks very rarely because for some reason I had the impression they were bad coding practice

[gildor]

it make sense if you have abstraction, but in this case instance check will not work, I would just choose what is better for your case

[gildor]

and don’t think about nanoseconds of difference

[Hullaballoonatic]

Got into the habit if it from writing code for data mining....

[gildor]

impression they were bad coding practice

Depends on case.
Checking Any for class is sometimes sign of some unnecessary usage of dynamic types, but not always
If you have Sealed class, than it just fine

[gildor]

Even for data mining… Those comparations on managed runtimes with JIT has even less sense and just measure difference is very hard, you need properly configured microbenchmark harness

[gildor]

Not for every case for sure

[gildor]

for example if boxing involved you can get big difference in performance

[Stephan Schroeder]

sealed classes are not the only reason class checks are ok in Kotlin, it’s also because classes are final by default. So you simply don’t run that often into the problems associated with class checks in Java.