-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
build: default to max jobs #1771
Conversation
Biggest problem I have with this is that I've seen |
@rvagg, thanks for the feedback. Those are both great points. I'll add my own negative having played with this some more. On memory-constrained systems, a job per core might run it out of memory entirely, and could cause an OOM crash. A small system like the Raspberry Pi has 4 cores, but only 1 GB of memory, and each job can use a decent amount of memory.
Then the default could be changed to a heuristic that also takes memory into account to reach a reasonable default (which can be easily overridden with the environment variable): const os = require('os');
function defaultJobs () {
const cpus = os.cpus().length;
const totalmem = os.totalmem();
const halfGig = 0.5*Math.pow(1024, 3);
// Rule of thumb, give each job a half gig of memory
return Math.min(4, cpus, Math.round(totalmem/halfGig));
} |
AFAIK all options supported by Lines 137 to 150 in b2e5cf0
|
@richardlau, you're right, I'd forgotten about that. The name is a bit awkward (especially if you're using So I guess the discussion is back to providing a new default that's greater than 1 job. |
the thing about |
Checklist
Description of change
This PR probably needs a little discussion on potential ramifications of the change.
Currently,
node-gyp
defaults to a single job, which means it only uses a single core out of the box. This causes unnecessarily slow builds on machines with multiple cores. While any given project can manually use this setting, I personally think a more reasonable default is to use all available cores. Otherwise build times are just longer than they need to be, especially with 4+ cores becoming more common. Applying this change will speed up builds for a lot of people.Any arguments for why this may not be a reasonable change? Is using more CPU during install an adverse change for some users?