Does TornadoFX still want to support Java complete...
# tornadofx
t
Does TornadoFX still want to support Java completely? Just interested, because I saw a lot of tiny functions that could be optimized by inlining
a
I am not sure what is this about. Tornado is made of extensions. It means that it looks really ugly from Java.
t
If I'm right, I remember that in the past, some choices are made to keep interoperability with Java better. (Don't know which ones, as it was a while ago) I do remember that the choice to support this interop was to make the migration from Java easier. But, If TornadoFX chooses to ignore Java, a lot of functions can be inlined. Or are there also other reasons not to do it?
a
Could you give an example of such place? I mean for an inline?
t
There are a lot of these, with almost no logic, but with lambda's
In short, functions that create/add a view, that have a body of around 4 lines and take a lamba. (almost all the functions in charts.kt)
a
They won't win anything from inlining. Basically, you get the benefit of inlining only in cases, the lambda could be transformed into a cycle. Allocation of additional object in case of builder wont' win you anything
t
The creation of lambda's don't have much overhead in normal code, but is pretty big if it can be optimized in a clockcycle?
a
UI builders are not the places you should optimize.
Inlining is not always a good thing and you deffinitely should not do it without first studyig actual performance impact.
t
Because of hotspots?
a
Because JVM has very good inlining as it is and it usually can do better than user. I've done some experiments in this regard. Inlining should be used only when you actually want to do loops inisde.
t
Ah, that's what you meant. I thought you meant a clock-cycle. And I understand. Thx for pointing this out!
b
IMHO, the only place where one would eventually see benefit would be in high volume data-dependent widget creation.