0

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?

captain-yossarian from Ukraine
  • 31,174
  • 3
  • 30
  • 62
  • 1
    There is no guarantee. However, an identity function is trivial to optimise - I just don't know if it is. With that said, a function call like this is hardly going to have a big impact. Identity is useful when trying to compose and manipulate functions on a higher level. If you're doing this, then you definitely have other calls combined together, so the identity call is probably the least in terms of execution. It very likely isn't worth optimising just for that. – VLAZ Mar 30 '21 at 07:51
  • @VLAZ hi. Thanks for comment. Please take a look here https://stackoverflow.com/questions/66851513/a-way-to-mark-arbitrary-strings-in-typescript-template-literals#answer-66852494 . Say I just want to create a varibale and check if value is valid HEX code. So , in this case there is no other functions – captain-yossarian from Ukraine Mar 30 '21 at 08:05
  • 1
    At a glance, it's *probably* OK. I don't expect this part of the application to be any sort of bottleneck. I do understand that the function call seems useless and...it sort of is. It's basically only there to satisfy the TS compiler. It would be cool if the TS compiler just emitted `const result = 'aaaaaf'` in JavaScript, stripping away the function but it doesn't. If it's any consolation, at runtime the JIT compiler will cut more corners for you automatically in the areas that need it most. If `hex('aaaaaf')` is called a lot, it's probably going to make it more efficient, too. – VLAZ Mar 30 '21 at 08:14
  • 1
    @VLAZ thnaks! Btw, there is a closure compiler for such kind optimizations. See here https://webpack.js.org/plugins/closure-webpack-plugin/ and https://developers.google.com/closure/compiler/docs/gettingstarted_ui – captain-yossarian from Ukraine Mar 30 '21 at 08:36

1 Answers1

2

(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, i.e. 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.)

jmrk
  • 34,271
  • 7
  • 59
  • 74