Interesting sometimes i use bind just for "partial application" 2012/6/9, Tim Caswell <[email protected]>: > 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 >
-- Enviado desde mi dispositivo móvil -- 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
