maximum call stack exceeded

[jonathanong]

tj/co#43

i'm guessing it's because of the callbacks and iteration count. any way of avoiding this?

[logicalparadox]

The async bench assumes that at some point during a single iteration user land will advance JS a tick, thus closing the loop/stack. I'm not familiar enough with co to say for sure, but my guess is that this variation of co's usage is not hitting any of the setImmediate blocks I see in the code.

I do know that with your mintime set to 1 you are not getting the most accurate results. Your benches are probably running the default of 100 iterations and the number you see is abstracted from that. Too low of a sample size for something that should run thousands of iterations in a second.

• For your bench that is causing call stack exceeded: if it's behavior is as it should be then you will need to convert that bench to sync to avoid problems.
• For your suite you should increase the mintime to 1500ms+ for the most accurate results.

/cc @visionmedia

[floatdrop]

I got same problem, while benchmarking bluebird promises. Increasing mintime is not helping. Could you look into code please?

[logicalparadox]

@floatdrop On node 0.10 I got the max stack size exceeded along with a bunch of errors about recursive nextTick calls. From your gist I changed process.nextTick to setImmediate these errors went away and the bench ran just fine. Hopefully that helped.

[floatdrop]

Yes, this solves it, thank you!

[LinusU]

It should be easy to let matcha determine if the callback was called in the same tick. It could then to the setImmediate if appropriate.

Or just use npm/dezalgo on the callback.