You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I have two ideas about functions inlining, that may be useful.
Automatically inline private (both static and non-static) class functions, if such functions are called just one time and their bodies and call contexts comply all the limitations for inlining. As an alternative user may allow such behavior by declaring (:allow_simple_private_functions_inlining) or similar annotation on class level. Or optimizer can just add VS Code's info level hint to problems panel for such functions during live code analysis. Or it can add info messages during build process. In other words, optimizer can do automatic inlining (by default or with user permission), if you as me think it is safe, or it can just warn user about the possibility to do such inlining.
Warn user if large function is inlined (either automatically or because of explicit (:inline) annotation) to more than one place. By "large" I mean functions with more than one (or two) expression like anything larger than function t(x, y) { f(y + 1, x - 1); } after all previous inlinings are done, but any other code size related metrics is fine too.
My story: I have a large class with a few dozens of small private functions that implement separate parts of heavy trigonometrical calculations, and these functions call each other. Most of them are called only once, while few others don't. I checked number of calls and added (:inline) annotation to almost all of them, but did one mistake by adding annotation to function that is called two times. After all other one-call functions inlining my two-call function's size became almost 150 lines, and this code is inlined to two places. As optimized code is barely readable because of "Minimize Locals" (and it's OK), and I haven't noticed it. And few months later I accidentally understood that and saved more than 1100 bytes by just removing (:inline). It would've been nice, if optimizer warned me earlier about such result and/or inlined small functions automatically leaving no place for user error.
Thank you.
The text was updated successfully, but these errors were encountered:
Hi, I have two ideas about functions inlining, that may be useful.
(:allow_simple_private_functions_inlining)
or similar annotation on class level. Or optimizer can just add VS Code's info level hint to problems panel for such functions during live code analysis. Or it can add info messages during build process. In other words, optimizer can do automatic inlining (by default or with user permission), if you as me think it is safe, or it can just warn user about the possibility to do such inlining.(:inline)
annotation) to more than one place. By "large" I mean functions with more than one (or two) expression like anything larger thanfunction t(x, y) { f(y + 1, x - 1); }
after all previous inlinings are done, but any other code size related metrics is fine too.My story: I have a large class with a few dozens of small private functions that implement separate parts of heavy trigonometrical calculations, and these functions call each other. Most of them are called only once, while few others don't. I checked number of calls and added
(:inline)
annotation to almost all of them, but did one mistake by adding annotation to function that is called two times. After all other one-call functions inlining my two-call function's size became almost 150 lines, and this code is inlined to two places. As optimized code is barely readable because of "Minimize Locals" (and it's OK), and I haven't noticed it. And few months later I accidentally understood that and saved more than 1100 bytes by just removing(:inline)
. It would've been nice, if optimizer warned me earlier about such result and/or inlined small functions automatically leaving no place for user error.Thank you.
The text was updated successfully, but these errors were encountered: