An IDE Inspection that suggests when to convert functions to inline functions

Language Design
1

My understanding is that inline functions have a performance benefit specifically when the function takes a lambda parameter. In that case, it seems like it would be useful to have an IDE inspection that finds all of the functions that can benefit from becoming inline. Does such an inspection exist? Or any other way to find functions that should be inlined via gradle or the kotlin compiler?

2

Inlining functions with lambdas does not guarantee performance boost. On the contrary, in many cases, inlining large function could cause visible performance regressions (even with lambdas in parameters). So you should not use inline unless you clearly understand what you are doing or performed measurements.

In general, inlines are meant for proficient library authors and should be used mostly for other benefits like reification and non-local returns.

3 Likes
3

I am not suggesting an inspection that tells junior developers what to do, though I understand how to that’s how my suggestion came off. I wasn’t thinking about an inspection that gives advice as much as one that helps productivity. Though perhaps it would also serve as an initial guideline for some.

I’m just suggesting a tool for an author who may have already decided that they want to inline most of their small functions that have a lambda parameter. This tool would help identify candidates for inlining (by, say, finding all functions with a lambda parameter and below X number of lines). It would just be an alternative to sifting through hundreds of files manually.

4

I do not think that “inlining most of your small function” is a good idea either. In most cases you need to decide case-by-case. So putting inline when you write function is much better. It would be interesting if you could share the benchmarking result with and without intines in your code.

1 Like
5

Thanks @darksnake and to be clear, are we talking just about runtime performance or is compilation performance a reasonable factor to consider too?

6

I am talking about runtime performance. Compilation is not strongly affected, if you do not count the byte-code size.

1 Like
7

BTW, compilation time can be severely affected, and even possibly result in methods that have too-much bytecode, IF you have an inline method that copies its lambda argument twice.
For instance, this will blow up the compiler:

inline fun doTwice(block: () -> Unit) {
  block()
  block()
}
fun main() {
  var counter = 0
  doTwice { doTwice { doTwice { doTwice { doTwice { doTwice { doTwice { doTwice { doTwice { doTwice { doTwice { doTwice { doTwice { doTwice { doTwice { doTwice { counter++ }}}}}}}}}}}}}}}}
  println(counter)
}

It is an imaginary example, but you can legitimately run into that if you nest different inline functions inside one another.

2 Likes