On and I've only managed to get the fans to audibly spin after several minutes of compiling an Android app with a huge native library on an x86 NDK for 4 architectures.
It literally takes 15 seconds to join a meeting with one of the fastest user computers available.
Absolutely horrible garbage of an app.
Microsoft has zero incentive to fix it, because they have a captive audience i. Their enterprise customers.
https://support.microsoft.com/en-us/office/change-settings-i...
An apples to apples comparison would require you to change the settings to disable autostart on Windows.
Even WhatsApp, which seemed to be a pretty light app, run smoother on Firefox than chrome or electron.
The beach ball occurs when some UI process does not service its event loop. This can be an issue with the process, or it can be caused because that process is contending for resources with the compilation processes.
If the critical resource that's causing a beachball here is CPU, there's two very easy paths forward: either modify your compilation scripts to use fewer threads than the system has physical performance cores, or run the compilation at a higher nice level. In either case the UI process should be able to get CPU when it needs it and not beachball. The higher nice level is generally both the easier and more effective solution, since it will allow the compilation process to continue to use all cores when UI processes are not scheduled.
If the critical resource is memory the system will page, which will turn the critical resource into disk bandwidth. Fixes specific to memory usage here are to get more memory (not really actionable), or to reduce parallelism on the build process.
If the critical resource is disk bandwidth, this is the hardest problem to fix. To my knowledge MacOS doesn't provide good tools for managing disk priority. If the disk bandwidth being used is to access build-related files (source, object files, etc) rather than swap, one possibility is to use a thunderbolt-connected external SSD for the build artifacts, leaving the internal storage for swap and for the UI program. However, if your build process is using so many disk operations that it's starving a UI program, you're likely to see a performance hit going to a slower external SSD.
It is not that the M-series chips can never trigger a beachball but that there are significantly fewer scenarios where that happens to the point that many users never find themselves in those scenarios. You see their enthusiasm as fanboyism and they could see you as being grumpy, but the you are just both seeing different parts of a distribution curve.
Also SpaceX doesn’t suck, you suck. :P
Chances are it has nothing to do with M1 and everything to do with your SSD being overwhelmed.
If you have this plus some of the other electron hogs (teams, slack, a browser with 30 tabs of stack overflow), your system does have a proper load.
Still no perceptible fan noise :)
There were a few 16" MBP models that could be equipped with 64gb of memory, before the Apple silicon transition.
Also worth noting, a lot of the older Intel chips also had memory capacities that went beyond 64 gigs. In theory Apple could have shipped a 128gb MBP.