Skip to content
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

perf: use cpu cores more efficently #705

Merged
merged 1 commit into from Feb 8, 2022

Conversation

Demivan
Copy link
Member

@Demivan Demivan commented Feb 8, 2022

Made adjustments to number of threads created. Vitest now uses more threads by default.

Implementation is just like in Jest:

In single run mode, this defaults to the number of the cores available on your machine minus one for the main thread. In watch mode, this defaults to half of the available cores on your machine to ensure Jest is unobtrusive and does not grind your machine to a halt.

minThreads is the same as maxThreads for now because of tinylibs/tinypool#23. This will cause a really small slowdown if number of test files is less than number of CPU cores. When Tinypool is fixed to better handle minThreads and maxThreads in isolate mode minThreads can be adjusted.

This improved performance of https://github.com/EvHaus/jest-vs-jasmine tests suite by 30% on my machine (16 cores)

@netlify
Copy link

netlify bot commented Feb 8, 2022

✔️ Deploy Preview for vitest-dev ready!

🔨 Explore the source changes: 28bdc6d

🔍 Inspect the deploy log: https://app.netlify.com/sites/vitest-dev/deploys/6202c7b079147500087fb0e3

😎 Browse the preview: https://deploy-preview-705--vitest-dev.netlify.app

@patak-dev patak-dev merged commit 3df5d8b into vitest-dev:main Feb 8, 2022
@vlazar
Copy link

vlazar commented Feb 9, 2022

What Ive observed with Jest is that using --maxWorkers=50% gives quite faster test run, than using all cores - 1. I've tried various numbers and half the cores seem to give a fastest test run for me.

Might worth trying. Maybe vitest has similar sweet spot somewhere lower than CPU cores - 1.

@Demivan
Copy link
Member Author

Demivan commented Feb 9, 2022

@vlazar Thanks for the info, I will check this out. We still have a lot of performance work to do.

chaii3 pushed a commit to chaii3/vitest that referenced this pull request May 13, 2022
)

* feat(useWebSocket): ✨  Added support for optional protocols parameter

Added support for an optional array parameter called protocols. This second parameter to the WebSocket constructor contains one or more protocol string to use e.g. subprotocols. If not provided, internally the parameter always default to an empty array (`[]`), so that was chosen as parameter initializer. More information can be found (here)[https://developer.mozilla.org/en-US/docs/Web/API/WebSocket/WebSocket].

* refactor(useWebSockets):  Moved protocols option to WebSocketOptions
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants