ci/macos: speedup builds#2185
Conversation
It looks like the make / ninja `-l` (cap jobs to load-average) option does not work well, resulting in slower builds, so disable its use and hard-code the maximum number of jobs to each runner's number of processors.
|
macOS users, @Commodore64user, @kodermike, how are build times on your machines? Our long does |
|
Real Macs just have the number of CPU cores they have without any virtualization weirdness so my hypothesis would be it'll matter less in whichever direction it goes. |
|
That's what I'm thinking, but I want to make sure. |
|
mac pro, 2.6 GHz 6-Core Intel Core i7 ran
for context (if it matters), full build: |
|
Thanks. Around ~10 minutes… Are those timings really with For comparison, I have an Intel Core i7-3770 (4 cores, 8 processors detected with multithreading), and If you install ninjatracing, you can get more precise build timings after a build by running |
|
Made me curious. On my Ryzen 7 7800X3D: |
show off ;) |
|
Before that I did a decade with an i7-4790. :-) The nice (or annoying?) thing is that if you now buy a reasonably priced i3 you get something similar but better. |
|
🤦 - that was with
|
Not really, if this is again with |
That's pretty bad performance (for the first command)… Did you forget to use |
|
I simply copied the command given above. I didn't realize it was wrong. In any event, the difference seems to be minimal, and just as likely caused by playing a video.
Close to the complete opposite I'd imagine. I never compile for x86_64 release. |
|
Anyway, it looks like |
|
|
|
For unnecesary reference, And then with a hot ccache:
|
|
I think I'll make |
opt-out, no? non-parallel is taking like 30~40 mins here, currently at 75% still |
|
|
|
updated the can you make it so we all get Frezie's results please... |
|
Well, you made me paranoid I got distracted by rl, so ran again for posterity w/ w / parallel letting the aircraft carrier rest now. |
It looks like the make / ninja `-l` (cap jobs to load-average) option does not work well, resulting in slower builds, so disable its use and hard-code the maximum number of jobs to each runner's number of processors.

It looks like the make / ninja
-l(cap jobs to load-average) option does not work well, resulting in slower builds, so disable its use and hard-code the maximum number of jobs to each runner's number of processors.This change is