Yes, it's possible to optimize them using specialized ICs on the proxy
handler itself, but it would be *far* easier to optimize it if the ICs
weren't necessary in the first place, since you can just build it into
the proxy's type, almost like a lazily-generated vtable. It's just far
less work than the otherwise-necessary complex ICs you'd need
Even though it is in theory possible to optimize such proxies, it's
pretty complicated to set up, and JS engines aren't exactly magic.
Looking for web consulting? Or a new website?
Send me an email and we can get started.
On Tue, Aug 8, 2017 at 5:36 PM, Sam Tobin-Hochstadt
> On Fri, Aug 4, 2017 at 4:52 PM, Allen Wirfs-Brock <al...@wirfs-brock.com>
>> On Aug 4, 2017, at 2:22 PM, Mark S. Miller <erig...@google.com> wrote:
>> At https://github.com/tvcutsem/es-lab/issues/21 Tom and I have an idea (that
>> we should turn into a proposal) for a subtle change to proxy semantics that
>> * should break essentially no current code,
>> * repair the cycle detection transparency violation bug,
>> * enable many proxies to be *much* faster.
>> I actually don’t see why any semantic changes are needed to enable better
>> Proxy performance. One abstractions are sufficiently lowered, a proxy trap
>> invocation is just a series of procedure calls (some dynamically
>> dispatched; some to built-in procedures). I don’t see any reason why the
>> same sort of PIC+dynamic typed based specialization+inlining that is used to
>> optimize more conventional JS code isn’t also applicable to Proxy using
> Indeed, this works well in practice with other proxy constructs in
> other languages -- my collaborators and I have a paper showing this
> that should be out soon. The only barrier to good proxy performance is
> implementation work.
> es-discuss mailing list
es-discuss mailing list