3 ms·

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 develo

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 https://github.com/jdelman/proxy-lens (Btw, I know calling it a lens isn’t right.)

goodoldneon 8y ago
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 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.
chrisseaton 8y ago
> 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?
- RussianCow 8y ago
  Proxies are entirely a runtime API. Did you read the article?
  - chrisseaton 8y ago
    > 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.
    - pxndx 8y ago
      They don't get compiled away because Proxies are a runtime thing. The impact on performance is entirely on the runtime.
      - 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.
iaml 8y ago
I don't know if it's a subtle joke, but I think you have a typo in readme.md s/pointdexter/poindexter.

goodoldneon 8y ago

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 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.

chrisseaton 8y ago

> 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?

RussianCow 8y ago
Proxies are entirely a runtime API. Did you read the article?
- chrisseaton 8y ago
  > 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.
  - pxndx 8y ago
    They don't get compiled away because Proxies are a runtime thing. The impact on performance is entirely on the runtime.
    - 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.

iaml 8y ago

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