Amin Ya

> Any news? In parcel@nightly, #5049 is fixed that added a bunch of features related to JSRuntime to the Electron environment (like using dynamic imports). If there is anything specific,...

I think Parcel should set the default number of Workers to 1 or something reasonable like 2 or 4. Using too many workers is **SLOWER** than just using 1 worker....

> > Could you check what > > https://github.com/parcel-bundler/parcel/blob/e183e32c811f066310fff0610aa856ca73a2fcb6/packages/core/workers/src/cpuCount.js#L49-L52 > > returns on your machine? That is used as the default `PARCEL_WORKERS` value on Windows. > I think we should...

> > It returns 16 which is correct > > (It should return 8 because that function is supposed to determine the number of real cores and not threads.) I...

Wrong benchmark Running the benchmark using Parcel 2.0.0-nightly.520 gives another result. Using workers is slower altogether! No matter how many. ``` // disclaimer: these fluctuate. Running the command the second...

Sorry! I made a mistake in the Powershell command for this benchmark. I thought `.Milliseconds` converts the whole time to milliseconds, but it just returns the milliseconds part (without seconds)!...

OK, here is the correct benchmark. Still, increasing the number of workers has no effect. Worker number Time (s) 0 9.72 1 10.63 2 10.18 4 10.42 6 10.37 8...

Here is the profile: [profile-20210109-161111.zip](https://github.com/parcel-bundler/parcel/files/5791916/profile-20210109-161111.zip) What I see is that in the Node file system a lot of `sync` methods are used instead of using `async` methods and letting Windows...

> Based on the profile I see a couple things: > > 1. Was this profile done without workers? I only see the "Master" thread. No. The worker number was...

> not sure why it's slower in your case. Tested with Yarn & pnpm on macOS and Yarn on Windows. I used Powershell for timing. Parcel itself reports almost 4...