3 ms·

It feels like it's rehashing and verifying every file in the OS.

c7DJTLrn 5y ago
Yet at the same time it doesn't feel like it's doing any work. It's an M1 Pro but I still don't hear the fans kick in or feel it warming up at all. So I feel like there is probably room for optimisation, whatever the update process does.
- ksec 5y ago
  That is just M1, it sure eat up all CPU when doing it on x86.
- jeffbee 5y ago
  macOS schedules software updates on the "efficiency" cores of the M1, which is why it takes forever and doesn't seem to cause any slowdown.
  - c7DJTLrn 5y ago
    Thanks for the info. Wow, any idea why? How do you know this?
    - jeffbee 5y ago
      I noticed it in Activity Monitor one day, then I looked at the docs and it’s a documented behavior.
  - booi 5y ago
    That’s actually pretty amazing. But sometimes I’ve set aside time to do the update and I’d like it to go as fast as possible. I wonder if there’s a way to force it on the performance cores?
    - jeffbee 5y ago
      Yes, I agree entirely. Once I wasted a half work-day waiting for Xcode to install itself, which is how I came to discover and research this feature. I would have much rather used my four fastest-you-can-buy cores than waste a morning waiting.
  - rbanffy 5y ago
    It should probably use all cores while there is an Apple logo and a progress bar (and the user is essentially locked out). Fun detail - newer IBM mainframes enable all cores (including the ones that are there but you didn't pay for) during the boot process to reduce downtime.
unphased 5y ago
Pretty sure it does do this.
- shbooms 5y ago
  I had that same hypothesis as well until recently when I disabled some unnecessary daemons by 1. booting into Recovery with SIP disabled and 2. changing a handful of the /System/LaunchAgents/*.plist files to .plist.bak files, effectively disabling for all future reboots. Since doing this, I've gone through a few security updates and was expecting the udpates to find that the original .plist files were missing and put them back in, but alas they did not as they remained as is.

Yet at the same time it doesn't feel like it's doing any work. It's an M1 Pro but I still don't hear the fans kick in or feel it warming up at all. So I feel like there is probably room for optimisation, whatever the update process does.

ksec 5y ago
That is just M1, it sure eat up all CPU when doing it on x86.
jeffbee 5y ago
macOS schedules software updates on the "efficiency" cores of the M1, which is why it takes forever and doesn't seem to cause any slowdown.
- c7DJTLrn 5y ago
  Thanks for the info. Wow, any idea why? How do you know this?
  - jeffbee 5y ago
    I noticed it in Activity Monitor one day, then I looked at the docs and it’s a documented behavior.
- booi 5y ago
  That’s actually pretty amazing. But sometimes I’ve set aside time to do the update and I’d like it to go as fast as possible. I wonder if there’s a way to force it on the performance cores?
  - jeffbee 5y ago
    Yes, I agree entirely. Once I wasted a half work-day waiting for Xcode to install itself, which is how I came to discover and research this feature. I would have much rather used my four fastest-you-can-buy cores than waste a morning waiting.
- rbanffy 5y ago
  It should probably use all cores while there is an Apple logo and a progress bar (and the user is essentially locked out). Fun detail - newer IBM mainframes enable all cores (including the ones that are there but you didn't pay for) during the boot process to reduce downtime.

unphased 5y ago

Pretty sure it does do this.

shbooms 5y ago
I had that same hypothesis as well until recently when I disabled some unnecessary daemons by 1. booting into Recovery with SIP disabled and 2. changing a handful of the /System/LaunchAgents/*.plist files to .plist.bak files, effectively disabling for all future reboots. Since doing this, I've gone through a few security updates and was expecting the udpates to find that the original .plist files were missing and put them back in, but alas they did not as they remained as is.