Hacker News Reader

Comment by turdnagel | Hacker News Reader

I love proxies. I do worry about their effects on performance, but the benefit of being able to use native object semantics is sometimes too great.

I’ve developed a proof-of-concept library that uses them to provide optionals support (no more TypeErrors for writing things like obj.property.property2.property3 when property doesn’t exist) here: https://github.com/jdelman/proxy-lens

(Btw, I know calling it a lens isn’t right.)

View on HN

Yea, Proxy performance can be an issue, especially if you use them recursively. I tried using them to create a "protected" clone (https://github.com/goodoldneon/alhambra). The initial "clone" is much more performant than actually deep cloning, and doesn't get more expensive as the size of the original increases. However, get/set/delete/etc. is far less performant.

I don't know if it's a subtle joke, but I think you have a typo in readme.md s/pointdexter/poindexter.

> I do worry about their effects on performance

What kind of performance do you mean? Compile time? They should be optimisable away and shouldn't have any effect on actual run time should they?

Proxies are entirely a runtime API. Did you read the article?

> Proxies are entirely a runtime API.

Yeah I know - but where isn't the performance as good as it should be? Is it during compile time, runtime, memory, something else? Do they not get compiled them away so they're free in terms of runtime cost?

> Did you read the article?

Yes of course I read the article. It's against HN guidelines to ask people this.

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?

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.

I don't mean Babel source-to-source compilation. I mean the native compilation done at runtime. The JIT.

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

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.

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?

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.

Reply on news.ycombinator.com