4 ms·

They don't get compiled away because Proxies are a runtime thing. The impact on performance is entirely on the runtime.

by pxndx 8y ago

chrisseaton 8y ago
I have no idea what you are trying to say. I know they're a runtime thing. Why is it not possible to optimise them away so they don't have a runtime cost, after having been compiled?
- pxndx 8y ago
  Because they need runtime support from the engine, e.g. you need engine support in order to intercept calls like: obj[prop] = 'foo' where prop is user input or similar. You could technically compile them away if you replaced all property set/gets with code like set(obj, prop, "foo") get(obj, prop) with a babel step, but the performance impact of this (both in runtime and compile-time) would be enormous.
  - chrisseaton 8y ago
    I don't mean Babel source-to-source compilation. I mean the native compilation done at runtime. The JIT.
    - pxndx 8y ago
      There's some work being done on optimising Proxies, but the current implementation is just slow (and also varies by engine), but yes, they can probably be optimised further. EDIT: there are various blog posts around talking about optimisation: https://v8.dev/blog/optimizing-proxies https://v8.dev/blog/optimizing-proxies
- fro0116 8y ago
  It's not possible to pre-compile away the dynamic part of a Proxy's behavior. For instance, if you were to receive a random string over some network call and set that on a proxified object, how would you pre-compile the Proxy away such that its runtime behavior is preserved when accessing what could be any arbitrary string? You'd need infinite space to represent the space of all possible string inputs in order to optimize that away at compile time, which is obviously not feasible.
  - chrisseaton 8y ago
    I know you can't AOT compile it away, that seems obvious, but what's the limitation that means you can't JIT compile it away? Like any other JS optimisation such as inline caching?
    - fro0116 8y ago
      JIT isn't really compiling the runtime performance penalty of the Proxy "away" though. JIT compilation still involves a runtime performance penalty of the JIT compilation step itself, that has to be traded off against the runtime performance penalty of just running the Proxy logic without any runtime compilation step. That's a nuanced tradeoff that has to be weighed on a case by case basis by various heuristics, and can reduce the runtime cost of proxies when applied to the right cases (and at the same time, could increase runtime cost if applied to the wrong ones: think overly aggressive inlining and its effects on memory usage), but either way it doesn't result in the Proxy abstraction becoming "compiled away" into something that has 0 runtime cost.
      - deleted 8y ago
        [deleted]

They don't get compiled away because Proxies are a runtime thing. The impact on performance is entirely on the runtime.

by pxndx 8y ago

They don't get compiled away because Proxies are a runtime thing. The impact on performance is entirely on the runtime.

I have no idea what you are trying to say. I know they're a runtime thing. Why is it not possible to optimise them away so they don't have a runtime cost, after having been compiled?

pxndx 8y ago
Because they need runtime support from the engine, e.g. you need engine support in order to intercept calls like: obj[prop] = 'foo' where prop is user input or similar. You could technically compile them away if you replaced all property set/gets with code like set(obj, prop, "foo") get(obj, prop) with a babel step, but the performance impact of this (both in runtime and compile-time) would be enormous.
- chrisseaton 8y ago
  I don't mean Babel source-to-source compilation. I mean the native compilation done at runtime. The JIT.
  - pxndx 8y ago
    There's some work being done on optimising Proxies, but the current implementation is just slow (and also varies by engine), but yes, they can probably be optimised further. EDIT: there are various blog posts around talking about optimisation: https://v8.dev/blog/optimizing-proxies https://v8.dev/blog/optimizing-proxies
fro0116 8y ago
It's not possible to pre-compile away the dynamic part of a Proxy's behavior. For instance, if you were to receive a random string over some network call and set that on a proxified object, how would you pre-compile the Proxy away such that its runtime behavior is preserved when accessing what could be any arbitrary string? You'd need infinite space to represent the space of all possible string inputs in order to optimize that away at compile time, which is obviously not feasible.
- chrisseaton 8y ago
  I know you can't AOT compile it away, that seems obvious, but what's the limitation that means you can't JIT compile it away? Like any other JS optimisation such as inline caching?
  - fro0116 8y ago
    JIT isn't really compiling the runtime performance penalty of the Proxy "away" though. JIT compilation still involves a runtime performance penalty of the JIT compilation step itself, that has to be traded off against the runtime performance penalty of just running the Proxy logic without any runtime compilation step. That's a nuanced tradeoff that has to be weighed on a case by case basis by various heuristics, and can reduce the runtime cost of proxies when applied to the right cases (and at the same time, could increase runtime cost if applied to the wrong ones: think overly aggressive inlining and its effects on memory usage), but either way it doesn't result in the Proxy abstraction becoming "compiled away" into something that has 0 runtime cost.
    - deleted 8y ago
      [deleted]