Proxy performance: JIT-compilation?
allen at wirfs-brock.com
Wed Aug 9 01:18:59 UTC 2017
> On Aug 8, 2017, at 5:03 PM, Mark Miller <erights at gmail.com> wrote:
> So from y'all's various implementation perspectives, how does https://github.com/tvcutsem/es-lab/issues/21 <https://github.com/tvcutsem/es-lab/issues/21> look? Do you think it would make it easier to achieve much higher performance proxies than we could without these subtle semantic changes? Or do you think we can as easily achieve these performance gains with no observable changes at all?
Detecting mutation of an handler object seems isomorphic to deleting mutation of an object on the [[Prototype]] chain of an ordinary object. I suspect a smart implementation would use the same detection/invalidation techniques for both. Sure an immutable handler object (or prototype object) may eliminate the need for that check, but the mechanism is going to have to be there anyway since most prototype objects are mutable. The basic idea is too lower every abstraction to primitive; highly optimizable IR. It has to me able to optimize potentially mutable dispatch objects (prototypes, etc.) even though actual mutation is very rate. So, not clear if special casing non-mutable dispatch objects would be worth added complexity. Obviously, milage may vary among actual designs.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss