我们对 JS 中的箭头函数优化有什么保证吗？

Question

Let's say we have next function:

const x = a => a;
const result = x('hello')

Do we have any guarantees in Google V8 / Firefox Quantum that x will be optimized to const result = 'hello' ?

Why I'm asking it?

Please see my answer . Some times the only way to infer type in TypeScript is to make simple function.

type Validation<T> = T
const x = <T>(arg:Validation<T>)=>arg

It is an overhead. So, I'm curious, can I use such kind of technique for type infering and don't worry about function overhead?

Answer 1

(V8 developer here.)

Generally speaking: there are no guarantees about what will or won't get optimized. An engine's optimization decisions also change over time: the goal is not to optimize as much as possible (because optimization itself has a cost that isn't always worth it); the goal is to optimize the right things at the right time. That may well mean that an engineering team decides to make their engine optimize a little less, for overall better performance (or less jankiness, or less memory consumption, or whatever).

What will likely happen in this specific case: it depends (as usual). If that function's definition and its call site are top-level code (executed a single time), it is very likely that it won't get optimized -- because optimizing such code is usually not worth it. You won't be able to measure the difference, but if you were able to measure it, you'd see that not optimizing is faster for code that runs only once.
If, on the other hand, this identity function is called from "hot" code, where that hot code itself is selected for optimization after a while, then it's very likely that the optimizing compiler will inline the function, and then (trivially) optimize it away.
If the definition of the identity function is executed repeatedly, then (at least before/unless inlining happens) this will unnecessarily create several function objects (because JavaScript functions have object identity). That's an inefficiency that's easy to avoid (so I'd avoid it, personally); but again: whether it really matters, ie whether it has a measurable effect, depends on how often the code is executed.

In short: it's probably fine not to worry about function overhead in such a case; however there is no guarantee that calls to the identity function will get optimized away.

(Taking a step back, looking at the broader background: I don't know much about TypeScript's advanced features, but my gut feeling is that some sort of plugin for the TS compiler might be a more elegant way to enforce particular typechecks for literals. If strings are constructed at runtime, then TS's checks won't help anyway, just like the rest of TS's type checking system.)