FWIW, my experience with .bind on V8 has always been that it's actually significantly slower than just creating a closure yourself. For a microbenchmark, see http://jsperf.com/bind-vs-closure
Besides the memory overhead of using bind vs calling with call, bind has strange semantics. For example, many developers don't know that you can't rebind a function. It's rather opaque and weird. I don't *like* working with bound functions. I do it many times anyway because the syntax is rather pretty and the performance of that part isn't critical. On Fri, Jun 8, 2012 at 7:34 PM, Rick Waldron <[email protected]> wrote: > > On Friday, June 8, 2012 at 8:29 PM, Jimb Esser wrote: > > Binding more than once is very common > > The bound function returned by fn.bind cannot be rebound and will silently > ignore any attempts to do so. > > > > - any code that is written with > a closure instead can be written with a static function and a .bind > (and, in general, be more efficient, causing less heap pressure). > > I think you might be misusing terminology. Perhaps you could share a code > example that illustrates your claim? > > Rick > > > > But, yeah, the immediate bind vs call was just in response to AJs > query, and it's pretty clear there's no reason to do that > (unless .bind was magically efficient, which it's not, it's just > generally more efficient than a new closure). > > > > On Jun 8, 5:22 pm, Rick Waldron <[email protected]> wrote: > > On Fri, Jun 8, 2012 at 7:23 PM, Jimb Esser <[email protected]> wrote: > > [Moved to nodejs instead of nodejs-dev since this is of general interest > and only tangental to the original request] > > > I've never thought of using .bind instead of .call, but since .bind does > allocate something, and .call theoretically doesn't have to, I'd just > assume .call is more efficient, though I've learned any performance > assumptions about JS are usually incorrect ^_^. > > > Doing a quick jsperf test of the things discussed here: > http://jsperf.com/bind-vs-call2 > Results are... questionable, and I don't put too much stock in micro-tests > like this, as the optimizer is good at making them go fast in inconsistent > ways. But, anyway, f.call(o) is way faster than f.bind(o)(), which is not > surprising. Slightly surprising, .bind seems to underperform closures > significantly in this case, though (at least on the older version of V8 > node is using), in real-world apps (at least, ours), I'm pretty certain > .bind is generally better... also allocates less memory (although in a > micro-test like this V8 likely effectively optimizes out any memory > allocations from the no-op closures). > > > This comparison is unbalanced -- when would you ever bind() more then once? > The bound function cannot be rebound. Furthermore, when would you ever > bind() and immediately execute? Never - because the correct approach is to > use call() when immediate invocation is required. bind() is one shot deal > that returns a new bound function to be called later. > > Rick > > > > > > > > > > - Jimb Esser > > > On Fri, Jun 8, 2012 at 3:14 PM, AJ ONeal <[email protected]> wrote: > > > Interesting. So have you found bind() to be more or less efficient than > .call() and or .apply()? > > > AJ ONeal > > > On Fri, Jun 8, 2012 at 3:48 PM, Jimb Esser <[email protected]> wrote: > > > Technically, at least in V8, .bind is a lot lighter weight than an > anonymous function. There are a large number of micro-benchmarks to look > at on jsperf.com, but for an actual anecdote, at one point we > accidentally required in a module which overrode Function.prototype.bind > with something that created an anonymous function (some browser-support > code for pre-.bind browsers), and our performance tanked, garbage > collection times increased significantly. > > > On Fri, Jun 8, 2012 at 2:25 PM, AJ ONeal <[email protected]> wrote: > > > If I'm not mistaken, bind() has the same technical drawbacks as using > an anonymous function (higher memory usage, more garbage collection, and > slower says Tim), but it does solve the maintainability / prettiness issue. > > > I just want to point out that Raspberry Pi is now shipping. > NodeJS is a very attractive option for development. > > > My own experience with my ARM-based media server has lead me to be a > believer in prototypes and leaner code. I can't say that one little anony > here and there is going to blow up an application, but I know for a fact > that there are significant performance gains when they are avoided. > > > I know it doesn't seem like a big deal now. But one day you may change > your mind. > > > AJ ONeal > > > On Fri, Jun 8, 2012 at 2:22 PM, George Stagas <[email protected]>wrote: > > > No need to change the API, we have .bind() - use the language > features, don't reinvent them. > > > 2012/6/8 Tim Caswell <[email protected]>: > > > On Fri, Jun 8, 2012 at 2:10 PM, tjholowaychuk < > > [email protected]> > > wrote: > > > what's wrong with .bind() ? > > > Mainly the overhead. Bind creates a new function every time it's > > called, > > and calling the bound function is a bit slower, especially in V8. > > (Insert > > statement about performance only mattering if it's significant...) > > > I usually will bind all my methods from the prototype that will be > > used as > > callbacks to the instance itself inside the constructor. This gives > > me a > > ton more "own" properties, but otherwise is fairly elegant. > > > On Jun 8, 11:52 am, AJ ONeal <[email protected]> wrote: > > emitter.on('data', myModule.dataHandler, myModule); > > > Even if myModule were to subclass EventEmitter, wouldn't I still > > need to > > pass in the `myModule` instance so that I get the correct `this`? > > I > > don't > think I understood what you meant by that. > > > And then these cases as well: > > > fs.readFile(file, encoding, myModule.fileHandler, myModule); > > > process.nextTick(myModule.tickHandler, myModule); > > > The list goes on. Obviously not a small project. Not difficult > > either, > > just > tedious. > > > AJ ONeal > > > On Fri, Jun 8, 2012 at 12:42 PM, Tim Caswell <[email protected] > > > wrote: > > Actually event emitters already call in the scope of the > > emitter, so > > there > is no need for a specific "this" value there. Just subclass > EventEmitter > and use normal methods. > > > On Fri, Jun 8, 2012 at 1:34 PM, AJ ONeal <[email protected]> > > wrote: > > > If you're going to use `this` then you must have a callback. > > It would > > make no sense to have a `this` and nothing to apply it to. > > > You think EventEmitters would feel the overhead of the if? > > > // context is Array, Object, or Function. > // Numbers, Strings, and Booleans need not `apply` (very > > punny) > > if (context) { > fn.call(context, a, b, c); > } else { > fn(a, b, c); > } > > > As far as the guesswork, well, I hear you on that. I've > > already done > > my > ranting at UtahJS Conf. Put this as one more in the bucket of > > reasons > > that > callbacks-last was not a well-thought out idea.... > > > AJ ONeal > > > On Fri, Jun 8, 2012 at 12:27 PM, Tim Caswell < > > [email protected]> > > wrote: > > > I think it's a useful addition, but it does cause a little > > overhead > > (though it's probably not noticeable compared to the actual > > work the > > async > function is doing). EventEmitters might feel the pain since > > they > > are sync. > I do worry that it makes things harder for our argument > > guessing > > code that > assumes the last arg is a callback. Now there will be an > > optional > > argument > after the callback that can be anything (including another > > function) > > > On Fri, Jun 8, 2012 at 1:18 PM, AJ ONeal <[email protected]> > > wrote: > > > Yes, That's what I am suggesting. > > > AJ ONeal > > > On Fri, Jun 8, 2012 at 12:17 PM, Tim Caswell > <[email protected]>wrote: > > > So this proposal is to modify the API of all async > > functions to > > have > an extra thisp argument after the callback argument (like > > done in > > Array.prototype.forEach)? > > > On Fri, Jun 8, 2012 at 1:06 PM, AJ ONeal < > > [email protected]> > > wrote: > > > I would like to propose that an additional parameter, > > `context` > > be > added to core node modules that accept callbacks to give > this-ness to the > callback. > > > The reason being is that I'm trying to eliminate anonymous > callbacks > from my code and have generally cleaner, more readable > > code (as > > well as > lower memory usage and less garbage collection). > > > I don't know if this has been discussed before, but I'd > > like to > > put > it on the table. > > > AJ ONeal > > > -- > Job Board:http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
