Proxy performance: JIT-compilation?

[kai zhu]

of course Proxy is going to cause deoptimization problems when you start breaking assumptions about Object builtins (which obviously have more aggressive and specialized optimizations than generic methods).  in v8, i understand the common-case optimization for builtin getters to be a direct property lookup of a c++ hidden class.  adding a trap with dynamic-code to the getter throws that direct-lookup out the window and likely no reasonable amount jit-optimization will get you back the common-case performance.

> On Aug 5, 2017, at 8:22 AM, Mark Miller <erights at gmail.com> wrote:
> 
> Alex, I'll just point out that you are already engaged in the best kind of activity to get implementors to optimize these paths: Building a membrane library that can get widespread use, which encapsulate the complexity of proxies behind a more usable API, for which these proxy operations are the bottleneck. If these costs were sufficient to deter use of your library this would not be a good strategy. But *many* uses of membranes will be for cases where membrane crossings are rare compared to direct object-to-object interaction on either side of the membrane. For most of these, faster proxies will not matter. But for some of these, proxy performance will not be enough to deter use, but faster proxies would still produce a noticeably more pleasant experience.
> 
> This is a long term strategy. For the short term, if you can manage it, make proxy performance significant in some widely used benchmark suite.
> 
> None of this is meant to detract from the box of chocolate strategy. Try everything!
> 
> 
> 
> On Fri, Aug 4, 2017 at 4:30 PM, Alex Vincent <ajvincent at gmail.com <mailto:ajvincent at gmail.com>> wrote:
> So, how many boxes of chocolates do I need to send to the two big vendors in Mountain View?  :-)
> 
> It's been fifteen years since I seriously tried to profile C++ code, and I didn't really know what I was doing back then:  unfamiliar tools, and less competence in C++ than I would've liked.  What little knowledge of profiling I had back then has long since faded.
> 
> Even if I could generate a pretty picture of how long we spent in each code path, I wouldn't know how to interpret it.
> 
> I recently submitted a patch for improving error reporting in SpiderMonkey [1], so I can occasionally dip my toes in the JSAPI code...
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1383630 <https://bugzilla.mozilla.org/show_bug.cgi?id=1383630>
> 
> On Fri, Aug 4, 2017 at 2:52 PM, Allen Wirfs-Brock <allen at wirfs-brock.com <mailto:allen at wirfs-brock.com>> wrote:
> I don’t think the barriers to such optimization are technical.  It’s more a matter of convincing that engine implementors that doing the work (probably significant)  to optimizing Proxies in this manner is a sound investment and hight priority
> 
> -- 
> "The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own."
> -- Alexander J. Vincent, June 30, 2001
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> 
> 
> 
> 
> -- 
>   Cheers,
>   --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170805/7f317786/attachment-0001.html>