⚡️ Faster scheduling of scheduleSequence
#5614
Merged
+68
−26
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
**👀 Potentially risky** (risk: low) With #3891, our target is to make scheduling faster. Scheduling is one of the built-in arbitrary provided by fast-check. It aims to ease detection of race-conditions by offering a simple way to detect such issues in your code. Up-to-now the code was doing a bit too many await/then letting it give back the hand many times in a row while it could have been faster to take it back. Additionally, this past behaviour (that we are trying to fix with many PRs) used to be strange as awaiting 1 was ok, but 10-times was not. More precisely there was a number of await working and passed this number it stopped to work as usual and users started to need to use other approaches (drop the `waitAll`). This set of PRs not only addresses a potential perf concern but also clarify what should work so that it appears more determistic for the final users.
🦋 Changeset detectedLatest commit: 75a5e57 The changes in this PR will be included in the next version bump. This PR includes changesets to release 5 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Open in Stackblitz • @fast-check/examples @fast-check/ava
@fast-check/expect-type
@fast-check/jest
fast-check
@fast-check/packaged
@fast-check/poisoning
@fast-check/vitest
@fast-check/worker
commit: |
dubzzz
changed the title
scheduleSequence (#4717)scheduleSequence
|
👋 A preview of the new documentation is available at: http://6786c91660acafc5123277eb--dubzzz-fast-check.netlify.app |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #5614 +/- ##
==========================================
+ Coverage 94.77% 94.80% +0.02%
==========================================
Files 235 235
Lines 10034 10028 -6
Branches 2826 2827 +1
==========================================
- Hits 9510 9507 -3
+ Misses 524 521 -3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
With #3891, our target is to make scheduling faster. Scheduling is one of the built-in arbitrary provided by fast-check. It aims to ease detection of race-conditions by offering a simple way to detect such issues in your code.
Up-to-now the code was doing a bit too many await/then letting it give back the hand many times in a row while it could have been faster to take it back. Additionally, this past behaviour (that we are trying to fix with many PRs) used to be strange as awaiting 1 was ok, but 10-times was not. More precisely there was a number of await working and passed this number it stopped to work as usual and users started to need to use other approaches (drop the
waitAll).This set of PRs not only addresses a potential perf concern but also clarify what should work so that it appears more determistic for the final users.
Checklist — Don't delete this checklist and make sure you do the following before opening the PR
yarn bumpand flag the impacts properlyAdvanced
👀 Potentially risky (risk: low): Our scheduler implementation was not as fast as it was supposed to be. As such it accepted some intermediate frames to be issued in-between two executions possibly making some behavior looking buggy when users started to happen yet an extra awaiting thing in the loop.