Does type inference affect compile time?

A “debate” came up at work with a new team member who decided to add types to everything claiming it was faster to compile.

My initial reaction was I don’t know if that is accurate. My second reaction was sure maybe but are we talking sub millisecond?

Would I be correct in asserting that idiomatic Kotlin would be to prefer type inference where not required or only when it is not obvious?

Can you give an example where the type would be not obvious? I mean there are 2 options. Either you declare the type directly or the type gets inferred by the expression assigned to the value.

I have no idea how the Kotlin compiler works exactly but as every expression has one and only one type this should there should be no noticeable increase in compile time. Worst case the type can not be inferred immediately because the expression can not yet be compiled, but the same can happen with any type as well. The type could be declared in a different module which has not yet been loaded so the compiler has to wait to determine the type in either way (at least I think it does).

Also the compiler has to check whether the types match, so it needs to know both types anyway, The type of the expression on the left and on the right hand side.

Still it would be interesting if there are any benchmarks testing this. Maybe heavy use of generics influence this as well.

TL-DR: I don’t think it matters but I don’t really know :stuck_out_tongue_winking_eye:

I don’t really have an example no. There are times where IntelliJ will say that it cant figure out the type or recommends that you specify. For the most part though, it’s quite often not needed.

The code in question for this debate had things like

var myThing: MyThing = MyThing()

I called out to favor immutability using val, and that this is a very obvious case where type is not needed.

We are also talking about a repo containing less than 20 classes, so debating about compile speed seems a bit absurd to me, not to mention I doubt it was even actually measured.

Ok, I never had that happen to me :slight_smile:

I’m like 100% sure you would not notice any difference even in a project with multiple thousand lines of code.

Agreed

I think that explicitly specifying the type in cases it is not obvious is a good practice disregarding compile speed. Of course stating type in obvious cases does not make sense.
I have much larger code base and I did not have problems with compile time since 1.2. Of course it takes a bit longer than java, but the difference is not crucial.

I totally agree. But I also think explicitly specifying types where it is obvious is a bad practice as it just clutters the code with unnecessary information. On thing I personally hate about java is

SuperLongClassNameHereWhichNeverEnds someVariable = new SuperLongClassNameHereWhichNeverEnds()

kotlin is much nicer in regards to that

val someVariable = SuperLongClassNameHereWhichNeverEnds()

@Wasabi375 Syntax error, no new :smile:

Woops your right. That’s what you get when you have to write even a single line of java :blush:

1 Like

I have the same problem. Usually I try to write vals in Java code. If I notice that a lot, I just migrate the file to kotlin. Luckily, with @JvmDefault it is almost fully backward compatible. The only thing still braking is repeatable annotations.

Java 10 now has type inference for local variables (using ‘var’) but not for anything else. The same applies to C#.

As far as the original question is concerned, I’d be surprised if type reference adds much (if anything) to compile time. Even if the type is specified, the compiler still needs to figure out the type of the expression on the RHS to see if it’s compatible or not.

Of course, if you use type inference in cases where the compiler (or a human reader) is unable to work out what you want to do, then that’s going to slow down development and maintenance.

@brandonlamb Under the hood kotlin compailer take care of any type of variable you assign. That’s why kotlin called static type, this mean kotlin assign type at the compile time and can’t change at runtime.

Because of that we can omit of type any variable, return function. But not for high order function, function property, you need to assign specific type.

Assign all type for each variable you create this doesn’t make big difference. Why I says like that, even there are different compile time, that only made a different about nanosecond depends on your machine, for example cpu core, pool, register memory.

Conclusion, you no need to assign type for each variable, or return function in kotlin.

I think (of cause I didn’t test/measured that) including explicit type when compiler can do the work would take longer to compile.
Compiler need to parse the specified type and compare it to the type of the expression on the right.
With implicit type compiler only getting type of expression on the RH and assigns to the field. It is less work.

1 Like

If you are OK with using project Lombok for your Java code you can get var and val support in Java.

I do not like Lombok at all. It messed the bytecode and in my opinion is unnecessary. I do not have problems with Java verbatimness, especially as it is covered by IDE, what I was talking about is a bit of confusion when switching to forward type declaration and back.

I too avoided lombok for many years but they use it at my current job, primarily to get things that are built into Kotlin. Just wanted to say it was an option if you get to frustrated with the lack of car and call in Java.