maximum call stack exceeded

jonathanong commented 10 years ago

https://github.com/visionmedia/co/pull/43

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

logicalparadox commented 10 years ago

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 commented 10 years ago

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

logicalparadox commented 10 years ago

@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 commented 10 years ago

Yes, this solves it, thank you!

LinusU commented 9 years ago

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.

logicalparadox / matcha

maximum call stack exceeded #9