Feature request: inline function

[yinhaibo01]

such as : inline public int add(a, b): int { return a+b; }
It's very useful for performance

[RyanCavanaugh]

JavaScript runtimes already automatically perform function inlining; there's no need for TypeScript to do this given the complexity of doing it correctly.

[jlennox]

Inlining at the JS level vs the runtime level may not be wholly equal, however.

http://jsperf.com/do-add-inline-test

Chrome 43.0.2357.81:
6,391,069 vs 6,714,536

Internet Explorer 11.0.9600.17801
2,079,037 vs 17,248,948

Internet Explorer 8.0.7601.17514
57,947 vs 250,837

Firefox 38.0.1
13,654,068 vs 13,444,826

Runtime inling is slower in everything but firefox, and in the latest version of internet explorer it's 8.3x faster for the JS to be inlined!

Can you provide a counter example?

[danquirk]

Even if this particular example were representative of the majority of examples the results don't really suggest doing our own optimization pass is correct. Clearly in this case inlining the code doesn't actually make us faster everywhere, a meaningful number of your customers now experience slower code (even if only marginally, other cases may be worse). Then the fact that Firefox demonstrates this performance characteristic suggests it's entirely possible for IE and Chrome to eventually do the same (for this or other code patterns), at which point our optimization phase is now making your performance slower everywhere (and you only know this for each microbenchmark you manually inspect), while costing us time, adding complexity to our codebase and making the emitted JS farther from the TS that you wrote. Further, any optimization pass of this nature that you might want to make could just be handled by an existing JS optimizing tool whose sole goal is optimizing performance, something we will never be as focused on as a tool like that or the JS runtimes themselves.

The JavaScript runtimes do an immense amount of work to optimize your code, some based on static analysis, some based on runtime patterns, or something else entirely. We're simply never going to spend the same amount of effort as them on these problems (nor do we have enough information to do what they do) and the best thing we can do for your performance is to emit idiomatic code so that as they improve we emit JS that benefits from that: https://wingolog.org/archives/2011/08/02/a-closer-look-at-crankshaft-v8s-optimizing-compiler

[jlennox]

I should of said this before. I'm not for automatic inlining, but something closer to a macro statement.

Sadly, IE8 to IE11 will never become what version of IE ultimately does optimize this situation well. We'll be supporting those browsers for a very long time.

Thank you for the interesting link.

[danquirk]

@jlennox see also #2721

For your case perhaps you could define a decorator called inline and a post processing task could do the work of replacing the places you've determined inlining to be advantageous.

[dorontal]

I'm totally with jlennox here: this is not just his case, but a common good programming practices case.

Sometimes we like to write tons of little helper functions (that need not incur the overhead of function calls when the code is run) and are just there for code clarity.

[rzvc]

This would be very useful for user defined type guards.

[Zorgatone]

Yes I agree. I personally need this a lot

[silbinarywolf]

I think automatic inlining similar to Golang would be beneficial,
Even basic "getter" support (ie when you simply return 1 value from a function), would be a good start.

[RyanCavanaugh]

Just to reiterate: JS runtimes are extremely (extremely) good at this and you really shouldn't be worrying about this using logic acquired when writing C code.

For example, in the parser, we changed hundreds of instances from x = e; to x = f(); where f was just return e, all of which were in the hot path. We saw 0% change in runtime. 0%.

For any case where TS could determine that a function could be inlined, the JS runtime is already doing a better job of it.