Joe your stubbornness speaks volumes. If you'd have quit everything in life after spending 10 minutes and messing up once you wouldn't get anywhere. There's an ever-growing number of supporters of this kind of technology (435 followers on github for fibers, 222 for streamline) and to not even explore it because of baseless assumptions is silly. It's not my problem if you don't want to use fibers or streamline, I don't care.. but it becomes my problem when you literally make up lies about this software. It's good and robust software, I promise. There's a one time cost to learn some simple rules about how the software works and then you can look forward to *significant* reductions in lines of code written.
On Tue, Apr 10, 2012 at 3:01 PM, Joe Ferner <[email protected]> wrote: > I think I'm done writing benchmarks. Even if I come up with a > benchmark that shows streamline is faster I'm still not going to use > it and I couldn't recommend anyone else use it either. The community > as a whole doesn't back that kind of syntax so I couldn't submit a > module to npm if I wrote it using streamline. As I said before I can't > easily run my unit tests or deploy to my server environment. From the > little that I used it, it screws up the stack trace, you get weird > errors like "Function contains async calls but does not have _ > parameter" which IMO shouldn't be an error at all. And it obscures > what is really going on under the covers which you pointed out quite > well in your most recent comments. > > On Apr 10, 3:24 pm, Bruno Jouhier <[email protected]> wrote: > > Still, your bench is wrong because the two programs do different things: > > > > * The streamline program calls socket.write from the callback of the > > previous socket.write. So it does proper flow control and it won't > overflow > > output buffers. > > * The callback program calls socket.write in a loop, without chaining > them > > through the callbacks. No flow control here! > > > > So please, go back to the drawing board and come back with a fair bench. > > > > Hint: the callback version should not run the bench with a for loop, it > > should transform the loop into a recursion (which is what streamline > does). > > > > > > > > > > > > > > > > On Tuesday, April 10, 2012 5:32:45 PM UTC+2, Joe Ferner wrote: > > > > > On Apr 10, 11:12 am, Bruno Jouhier <[email protected]> wrote: > > > > Your bench does not make sense. There is no async call at all. So > there > > > is no reason to have an _ in the streamline source. > > > > > > Streamline does not transform sync fonctions. So the Streamline > version > > > of this bench should take 3 ms. > > > > > > Callback != asynchronous > > > > > > Try again with an async call > > > > > I was trying to demonstrate the call overhead but here is an example > > > with some async codehttps://gist.github.com/2352116again a bit > > > contrived because I really didn't want to spend much time on this. > > > > > streamline did close the gap a bit which is what I suspected when I > > > said "I will agree that for many real world cases this is a tiny piece > > > of the overall time". But it was still twice as slow. (node 565ms and > > > streamline 1049ms) > > -- > 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
