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

Use worker_threads #9

Open
JounQin opened this issue Jul 12, 2021 · 8 comments
Open

Use worker_threads #9

JounQin opened this issue Jul 12, 2021 · 8 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@JounQin
Copy link

JounQin commented Jul 12, 2021

See https://github.com/rx-ts/synckit/blob/perf/make-synchronous/benchmarks/benchmark.txt

It's about 300x slower.

@sindresorhus
Copy link
Owner

sindresorhus commented Jul 12, 2021

Yeah, I've been thinking about moving to worker_threads (and removing the current child process implementation). When I initially made this package, I was not aware that it could be done with worker_threads too.

@sindresorhus sindresorhus added enhancement New feature or request help wanted Extra attention is needed labels Jul 12, 2021
@sindresorhus sindresorhus changed the title child_process is much slower than worker_threads Use worker_threads Jul 12, 2021
@JounQin
Copy link
Author

JounQin commented Jun 27, 2022

Can I recommend user's to use synckit instead in the README?

@sindresorhus
Copy link
Owner

sindresorhus commented Jun 27, 2022

I plan on supporting worker_threads here soon.

@sindresorhus
Copy link
Owner

It's about 300x slower.

Your benchmark is flawed. You should run a heavy operation in the worker to actually test it, not just a lightweight task. Also, the task you are running in the worker (fs.promises.readFile) is already run in a background thread by Node.js.

@JounQin
Copy link
Author

JounQin commented Jun 27, 2022

I plan on supporting worker_threads here soon.

That's great, I would follow your changes then.

@mmkal
Copy link

mmkal commented Nov 9, 2023

@sindresorhus I came here wondering what the advantages are of this over synckit. synckit seems well thought, fairly feature-rich out and widely used - do you think it's worth maintaining this rival at this point? Is there something missing from synckit that make-synchronous does better, or will do better?

This is a genuine question - it's often hard to tell what the tradeoffs of various libraries are, and maintainers tend to know best.

@sindresorhus
Copy link
Owner

@mmkal This executes in a subprocess which has some benefits:

  • Complete isolation.
  • Cannot hang the process (worker threads can potentially hang the main process).
  • Separate memory limit, so you could execute something that takes a lot of memory.

Yes, it's slower to launch a subprocess, but that only matters if you use it for short-running tasks. For long-running intensive tasks, the difference is neglible.

@JounQin
Copy link
Author

JounQin commented Nov 10, 2023

Yes, it's slower to launch a subprocess, but that only matters if you use it for short-running tasks. For long-running intensive tasks, the difference is neglible.

Or if your task needs to be run many times, there will be huge difference too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants