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
