You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently electron-rebuild uses a single node-gyp job (the default) so it can only use a single core. With multi-core systems (should be almost all these days) this leaves a lot of performance on the table and results in slow builds.
The fix is easy enough, jobs N simply needs to be passed to node-gyp. I'll gladly make a PR, but wanted to discuss how it should look before putting any time into it.
Tested the change manually and on a rebuild on a Raspberry Pi, build time went from 1409 seconds to 693 seconds because it was able to use more cores. In theory it should have only taken ~350 seconds but I think it was I/O limited due to a slow disk.
The most obvious approach for exposing this option would be to add -j, --jobs Number of parallel jobs to use as an option for electron-rebuild, and pass this value to node-gyp. This would retain current behavior of only using a single job, but allow configuring more.
The downside to this approach is there's no automatic performance gain, people need to be aware of the flag and use it. There is the option to pass max to node-gyp which will set jobs to the number of cores available. If this was the default for electron-rebuild the performance boost would be available out of the box.
Currently
electron-rebuild
uses a singlenode-gyp
job (the default) so it can only use a single core. With multi-core systems (should be almost all these days) this leaves a lot of performance on the table and results in slow builds.The fix is easy enough,
jobs N
simply needs to be passed tonode-gyp
. I'll gladly make a PR, but wanted to discuss how it should look before putting any time into it.Tested the change manually and on a rebuild on a Raspberry Pi, build time went from 1409 seconds to 693 seconds because it was able to use more cores. In theory it should have only taken ~350 seconds but I think it was I/O limited due to a slow disk.
The most obvious approach for exposing this option would be to add
-j, --jobs Number of parallel jobs to use
as an option forelectron-rebuild
, and pass this value tonode-gyp
. This would retain current behavior of only using a single job, but allow configuring more.The downside to this approach is there's no automatic performance gain, people need to be aware of the flag and use it. There is the option to pass
max
tonode-gyp
which will set jobs to the number of cores available. If this was the default forelectron-rebuild
the performance boost would be available out of the box.@MarshallOfSound, thoughts?
The text was updated successfully, but these errors were encountered: