Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In #16, I noticed that Stardazed Streams were more than 2x faster than this polyfill. This sparked my interest, so I set out to find where this polyfill was spending the extra time.
I set up a benchmark suite using Benchmark.js to compare the performance of this polyfill and Stardazed's implementation on the code snippet from #15. Then, I used flamebearer to create the following flame graphs:
web-streams-polyfill
@stardazed/streams
I'm not an expert, but it looks like the polyfill's
reader.read()
spends a lot of time in some sort of built-in Node function.I went to compare the
ReadableStreamDefaultReaderRead
implementation ofweb-streams-polyfill
and@stardazed/streams
, and I only found one difference insideReadableStreamCreateReadResult
. The polyfill usesObject.defineProperty
to setvalue
anddone
:While Stardazed sets those with a regular property assignment:
Indeed, that fixes the performance issue! 🎉
Benchmark results before:
After: