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 <erig...@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 <ajvinc...@gmail.com > <mailto:ajvinc...@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 <al...@wirfs-brock.com > <mailto:al...@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@mozilla.org <mailto:es-discuss@mozilla.org> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > > > > > -- > Cheers, > --MarkM > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
