Results 788 comments of Benjamin Gruenbaum

> I would expect some of them to be natively written with async/await. How does that compare? What's the different between writing native async/await code and using `util.promisify`? Well that's...

@targos I'm unfamiliar with that approach - if @addaleax chimes in she might have done it. I benchmarked `util.promisify` vs a userland promisify and it was faster measurably on my...

I created two versions of native promises (one with `util.promisify` and one without) and removed everything but bluebird and native promises: ``` file time(ms) memory(MB) callbacks-baseline.js 162 32.80 promises-bluebird-generator.js 257...

@kyrylkov thanks! Given I did not share the code the fact we got similar results is reassuring. For comparison and until we decide where to put it - here is...

Thanks @targos, that's very interesting. Running those on the real (doxbee) benchmark after building Node from your source at that branch I get: ``` results for 10000 parallel executions, 1...

@targos updated the above with benchmarks both with V8 6.0 and 6.2 (6.2 by doing a git pull from your branch on top of node-v8's canary branch).

@littledan Thanks for chiming in! I think a nice design goal would be to optimize the 99% use case of using native promises only listened to by one observer in...

@addaleax @vsemozhetbyt see prior work at https://github.com/nodejs/readable-stream/issues/254 (ccing @mcollina ) I think that avoiding the two closures in readable streams is a good start - but allocating two promises would...

@vsemozhetbyt > Refs: https://medium.com/netscape/async-iterators-these-promises-are-killing-my-performance-4767df03d85b Very nice, it shows there are misconceptions and that async iterators are poorly communicated. For example this part: > The problem is that Promises have to...

Pinging @danvk to weigh in on their article :) I was thinking about holding the meeting the week after next week (I think we have enough to discuss at this...