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 >> > >> > >> > >
