-
-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use a single SharedArrayBuffer #154
Conversation
🦋 Changeset detectedLatest commit: 4a98a17 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #154 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 1 1
Lines 207 204 -3
Branches 103 100 -3
=========================================
- Hits 207 204 -3 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your awesome work! @onigoetz
As a replacement to PR #150 this is a new PR that uses a single SharedArrayBuffer instead of creating a new one on each call.
More precisely this PR brings the following changes:
SharedArrayBuffer
that's initialized once and passed to the worker at initialization timeSharedArrayBuffer
to 4 bytes; since it is only used for notification purposes, this is the only byte that is needed in this SharedArrayBufferbufferSize
option andSYNCKIT_BUFFER_SIZE
env variable as they are not needed anymore (they actually had no effect before either)bufferSize
as removing it would effectively be a backwards compatibility break and I think it's better to avoid it.Atomics.store
at the beginning of the function calling the worker to reset theSharedArrayBuffer
otherwise it would not wait for the resultHere is the benchmark accompanying this change:
Apart from the performance itself, this PR should also bring a much reduced pressure on the memory as it requires a single 4B SharedArrayBuffer per initialized function instead of a 1024B SharedArrayBuffer per call