Hacker News Reader

Comment by pronoiac | Hacker News Reader

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

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.

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.

Thanks for the info. Wow, any idea why? How do you know this?

I noticed it in Activity Monitor one day, then I looked at the docs and it’s a documented behavior.

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?

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.

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.

That is just M1, it sure eat up all CPU when doing it on x86.

Pretty sure it does do this.

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.

Reply on news.ycombinator.com