> 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?
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?
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.
obj[prop] = 'foo'
set(obj, prop, "foo")
get(obj, prop)
EDIT: there are various blog posts around talking about optimisation: https://v8.dev/blog/optimizing-proxies
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.
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.