3 ms·
Promises should not be a big overhead. If they are, that seems like a bug in JS engines. At a native level (C++/rust), a Promise is just a closure added to a l
by socalgal2 8mo ago
Promises should not be a big overhead. If they are, that seems like a bug in JS engines.
At a native level (C++/rust), a Promise is just a closure added to a list of callbacks for the event loop. Yes, if you did 1 per streamed byte then it would be huge but if you're doing 1 promise per megabyte, (1000 per gig), it really shouldn't add up 1% of perf.
- conartist6 8mo agoI'm fairly sure it's not Promises that are actually the heavy part but the `await` keyword as used in the `for await` loop. That's because await tries to preserve the call stack for debugging, making it a relatively high-level expensive construct from a perf perspective where a promise is a relatively low-level cheap one. So if you're going to flatten everything into one stream then you can't have a for loop implementation that defensively awaits on every step, or else it'll be slooooooooow. That's my proposal for the change to the language is a syntax like for await? (value of stream) { } which would only do the expensive high-level await when the underlying protocol forced it to by returning a promise-valued step.
- esprehn 8mo agoAsync call stacks is an optional feature when the devtools is open. There shouldn't be overhead from await like that?
- conartist6 8mo agoIt's awfully hard to know, and I am not myself sure.
- pornel 8mo agoIn Rust, a Future can have only exactly one listener awaiting it, which means it doesn't need dynamic allocation and looping for an arbitrary number of .then() callbacks. This allows merging a chain of `.await`ed futures into a single state machine. You could get away with awaiting even on every byte.