In the future wouldn't using a Function Proxy be potentially much faster?
On Fri, Jul 12, 2013 at 1:12 PM, K. Gadd <[email protected]> wrote: > I've had some back and forth with v8 devs about this since it affects my > compiler. I believe they already have open issues about it but I don't know > the bug #s. > > In general, the problem seems to be that Function.bind creates functions > that have different type information from normal functions you wrote in > pure JS; they're 'special' native functions in the same fashion as say, a > DOM API: > > document.createElement > function createElement() { [native code] } > function f () {} > f > function f() {} > f.bind(null) > function () { [native code] } > > This is important because v8 tries to gather information about callees at > various call sites. Having a mix of these special and non-special functions > means that the JIT is not able to make safe optimizations based on all the > callers being the same type. > > IIRC there are also some other problems specific to v8, like it only being > able to optimize Function.apply and Function.call if the .apply/.call > methods are the implementations used for pure-JS functions (so bind breaks > those too). > > I can't comment on why it's slow in SpiderMonkey (I've never asked... I > should file a bug) but it is indeed the case that f.bind(null) produces a > 'native code' function in SpiderMonkey, so I expect some of the same > optimization consequences apply. > > I also expect that it is much harder for v8 and spidermonkey to inline a > function that contains native code, if not entirely impossible. > > All of these problems, as I understand them, are completely fixable. It > might be as simple as making bind return a pure-JS function instead of a > native function. This is supported by the fact that a pure-JS polyfill for > .bind is usually faster in my tests. In general VM authors are much more > helpful when shown real world applications affected by these issues, based > on my experience. They tend to ignore jsperf microbenchmarks, etc. > > I don't know that this could be addressed at all from a specification > perspective. The only thing I can think of would be specifying that the > result of Function.bind should somehow be indistinguishable from a > hand-written JS function (no 'native code' in tostring, etc) but I don't > think that sort of spec requirement would actually prevent any of these > performance traps. > > Hope this helps, > -kg > > On Fri, Jul 12, 2013 at 10:59 AM, Brendan Eich <[email protected]>wrote: > >> Allen Wirfs-Brock wrote: >> >>> you might consider ticketing performance bugs against the various >>> implementations. >>> >> >> Right, and at most summarize with links to those issues for es-discuss. >> This is not a language issue, rather a quality of implementation one. >> >> /be >> >> >>> Allen >>> >>> >>> On Jul 10, 2013, at 9:16 AM, Claus Reinke wrote: >>> >>> The TypeScript project tries to emulate arrow functions through the >>>> "_this = this" pattern and keeps running into corner cases where a >>>> semi-naïve renaming is not sufficient. >>>> >>>> I have been trying to suggest using .bind to emulate arrow functions >>>> instead, but the counter-arguments are (a) .bind might not be available >>>> (supporting pre-ES5 targets) and (b) .bind is slow. >>>> >>>> The polyfill isn't the problem, but I'm a bit shocked every time >>>> someone reminds me of the performance hit for using .bind. Given >>>> that a bound function has strictly more info than an unbound one, >>>> I wouldn't expect that (I expected a bound function to be roughly >>>> the same as an unbound function that does not use "this"). Unless >>>> there is no special casing for the just-add-this case, and .bind is >>>> always treated as a non-standard (meta-level) call. >>>> >>>> While playing with test-code, I also found that v8 does a lot better >>>> than other engines when using an .apply-based .bind emulation. >>>> >>>> Can anyone explain what is going on with .bind, .apply and the >>>> performance hits? >>>> >>>> The TypeScript issue is >>>> https://typescript.codeplex.**com/workitem/1322<https://typescript.codeplex.com/workitem/1322>. >>>> My test code (*) is attached there as "bind-for-arrows.html". >>>> >>>> Claus >>>> http://clausreinke.github.com/ >>>> >>>> (*) I also tried to make a jsperf test case, but the way jsperf >>>> runs the loop seems to prevent the optimization that makes >>>> v8 look good for the .apply-based bind. >>>> >>>> ______________________________**_________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >>>> >>>> >>> ______________________________**_________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >>> >>> ______________________________**_________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- - Matthew Robb
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
