Remove internal Queue
leftovers
#238
Merged
+10
−136
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.
This changeset removes any internal
Queue
leftovers. This does not change outside behavior of this project and only cleans up unneeded code, so this does not break BC.This effectively reverts the remainder of the iterative logic introduced in #28/#82/#86. This logic has turned out to cause a number of problems in the past, so the behavior has been reverted as part of #229 already. This means that the iterative approach originally planned for Promise v3 is now reverted completely and the logic is in line with how Promise v2 and v1 behave. The test suite confirms my changes do not break any of the previous assumptions, so this should be safe to apply.
On top of this, this avoids a number of function calls and shows a significant performance improvement in synthetic benchmarks. For example, the following benchmark improved from
16.4s
to11.6s
3.1s
on my machine (best of 5 each):I still agree that an iterative approach sounds tempting, but at this point it's unclear what benefit this would actually bring and if it's worth breaking any of the existing behavior. I would suggest we should look into this iterative logic and its consequences again in a follow-up PR some time in the future if we see a need for this. Until we can come up with more specific test cases that highlight now this iterative logic is needed, I would argue that merging this as is to remove any unneeded code and to reduce our complexity seems reasonable.