Proxy performance: JIT-compilation?

[Isiah Meadows]

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

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

Isiah Meadows
me at isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Tue, Aug 8, 2017 at 5:36 PM, Sam Tobin-Hochstadt
<samth at cs.indiana.edu> wrote:
> On Fri, Aug 4, 2017 at 4:52 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>>
>> On Aug 4, 2017, at 2:22 PM, Mark S. Miller <erights at 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
>> code.
>
> 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.
>
> Sam
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss