https://kotlinlang.org logo
Join Slack
Powered by
For a function like this, does it make sense to ma...
# getting-started
v
For a function like this, does it make sense to make it inline?
Copy code
public inline fun Boolean.asGBoolean(): Int = if (this) 1 else 0
🚫 1
👀 1
h
I think (!), this is useless because the JVM will inline this at runtime
v
also when it's running on Kotlin/Native (which is the target)
h
I guess this is only useful if the kotlin compiler/llvm is able to do constant folding after data flow analysis and the resulting inlining. Otherwise, I don't think this is worth it. Keep in mind, llvm also optimizes the resulting kotlin code, so best thing is testing.
v
Thank you for the explanation, I'll add it to my experiment list
h
Please don't call it an explanation, but a guess.
l
I’ll often inline performance-critical methods that often get called repeatedly just to indicate to a future programmer what my intention is.
c
For Kotlin/Native optimization questions, you can take a look at https://godbolt.org/noscript/kotlin Keep in mind though that things like this can change between versions.
l
This seems to use the JVM compiler, not the K/N compiler.
It only lets you select kotlinc. Maybe once Kotlin 2.0 is out, they could merge the compiler binaries, but for now, you need kotlinc-native to compile Kotlin/Native.
e
c
I was sure the compiler explorer had Kotlin Native 🤔
l
They closed the PR, since they weren’t quite happy with the results. https://github.com/compiler-explorer/compiler-explorer/pull/2738
You could possibly compile it to llvm IR on your system, then use the LLVM IR option.
e
in any case, I think adding 
inline
is a terrible way to express the intention of "cheap function". it increases your compile time by inflating the intermediate IR, and excessive inlining leads to code bloat which causes worse performance due to icache misses. best leave it to the compiler or PGO to determine what makes sense to inline.
âž• 1
l
I’m not quite sure I’ve always trusted the compiler to optimize inline, since there’s a tradeoff of space vs speed. I have a method in one project where I know from benchmarks that if it becomes an actual function, there’s too much overhead, and I see a performance difference (this method is on all the the hottest parts of the loop). The compiler may decide to not inline it to save on space, but in this case, I want each instance to be inlined.
e
inlining can win at microbenchmarks while losing on overall application performance
l
This was before we had microbenchmarks. Our benchmarks were all running the program and automatically checking a few performance metrics.
v
for context: The use case for this particular function is basically every wrapped method that returns a native boolean, and needs to be converted to a Kotlin Boolean for my generated bindings
so we are always calling an existing native method from a shared lib through cinterop, which returns an Int, and needs to be a Boolean for the Kotlin caller
ah sorry, I pasted the GBoolean version, so this one is the other way around, everytime a Kotlin Boolean is passed as an argument to a cinterop native function
e
in that case I think it would be better to have it inlined into your generated code instead of having a 
inline fun
which becomes part of your ABI (unless you really want it to be)
âž• 1
l
I usually inline that, since there’s no way that method takes up more space than a function call, but the compiler may catch it.
v
true, and that's actually the simplest solution
9 Views
Open in Slack
PreviousNext
Powered by