also, this is "control flow", not "flow control". This near collision in nomenclature is most unfortunate, but "control flow" refers to the transference of control from one phase to the next. (this is the case you are discussing)
"flow control" refers to controling rates of (eg, data) flow through a system. Quite a different concept but also important in node -- when it comes to streaming. I really hate to be this anal, but it's just that I streams are a really great aspect of node and the more people that understand them the better, therefore I want to be as clear as possible. On Thu, Jun 21, 2012 at 11:30 PM, Mariusz Nowak <[email protected]> wrote: > Alan, we use asynchronous programming for tasks that take time, so in that > case, whether we wrap such tasks with closure or prototype solution wouldn't > make difference in performance. I think debating on performance in that case > is pointless. > > As a side node be sure to check also deferred/promises concept, it's much > more powerful than callbacks when dealing with complicated asynchronous > flow. > > > On Wednesday, June 20, 2012 2:33:41 PM UTC+2, Alan Gutierrez wrote: >> >> "The right way of coding nodejs applications" prompts me to post some >> benchmarks >> I was playing with a few days ago to answer this very question. >> >> My benchmarks looked at the performance of using closures for asynchronous >> flow >> control, where you are creating closures with each function call. >> >> A common model for flow control is to use closures. Here is an example >> from the >> delightful little `Step` library by Tim Caswell. >> >> Step( >> function readSelf() { >> fs.readFile(__filename, this); >> }, >> function capitalize(err, text) { >> if (err) throw err; >> return text.toUpperCase(); >> }, >> function showIt(err, newText) { >> if (err) throw err; >> console.log(newText); >> } >> ); >> >> I wanted to see how the creation of closures at function invocation would >> compare to the use of an object, where the steps would be object member >> functions and state would be preserved in `this`. Maybe creating an object >> would >> be faster since the member functions are already created, they only need >> to be >> assigned. >> >> I created a JSPerf that tested closures versus prototypes for this use >> case. >> >> http://jsperf.com/flow-control/3 >> >> The tests are not asynchronous. I only want to test the cost of creating >> the >> closures versus creating the object and fussing with `this`. >> >> Each function sums an array after after first popping the last element. >> The pop >> is one step. The sum is another. There is no external flow control. The >> popper >> function calls the sum function when it is done. >> >> Looks like the prototype method might be slightly faster, but not fast >> enough to >> make me want to explore using object member functions for flow control >> when >> closures are familiar and easy to read. >> >> Rough Edges >> >> I did find an interesting case where if you assign a method to an object >> member, >> as you might do during object creation, performance drops dramatically. >> This can >> be seen in "Closure assigned to object property" and "Closure assigned to >> object >> property, not called". >> >> However, you can make the problem go away if you assign the function to a >> variable, then assign the property using the function name. This can be >> seen in >> "Closure assigned to object property via variable". >> >> Also, performance in Firefox 13 is a different story. Using an object to >> model >> flow is all kinds of faster. >> >> Conclusions >> >> Maybe closures are a work in progress with a few gotchas, but it's >> probably not >> worth my time to create a convoluted new async pattern to second-guess V8. >> >> -- >> Alan Gutierrez - http://twitter.com/bigeasy - http://github.com/bigeasy > > -- > 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
