> On Jul 12, 2013, at 10:09 AM, "Mark S. Miller" <[email protected]> wrote: > > If you can manage it, most effective would be to get .bind (or any other > operation you want to be faster) into some widely quoted benchmark suite.
In WebKit at least, we have a thing called JSRegress which is meant to be a dumping ground for benchmarks for interesting corners of the language. Microbenchmarks are welcome; the goal is to just expand coverage of things that we measure timings of. It's not widely quoted, and it doesn't get the same priority as "macrobenchmark" suites, but we do care about it and we do optimize for it. For example, all of our optimization a for typeof, switch, and 'in' arose from JSRegress tests, since none of those things were hot enough in any of the "major" benchmarks. We don't have coverage for bind, and it would be great to fix that. If you have a standalone program that uses bind, you can either post a patch on bugs.webkit.org that adds it to JSRegress (I.e. LayoutTests/fast/js/regress/script-tests), or if you're lazy, you can just email the program to me and I can do the footwork. The less micro-benchmarky the better, but we'll take what we can get. If you have multiple such benchmarks for bind then that's even better still. TL;DR getting a benchmark to have visibility among implementors is as easy as telling them about it. -Filip > > >> On Fri, Jul 12, 2013 at 9:46 AM, Allen Wirfs-Brock <[email protected]> >> wrote: >> you might consider ticketing performance bugs against the various >> implementations. >> >> 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 . >> > 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 >> > >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > > > -- > Cheers, > --MarkM > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
