I recently had no choice but to upgrade to an M1 Macbook from an Intel-based one. I did not want to upgrade, as I’m working on a software for which performance on mid-range machines is critical, but unfortunately the previous laptop gave up on me. Since M1 macbooks are so much more powerful than previous generations, is there a way to intentionally slow it down to be able to test my program on a slower machine? One way I can think of, is to run the program inside a VM, but that would slow down the development loop.
Thanks for all the suggestions. Now I have the following list of tricks to try (collected from the thread):
- taskpolicy -b -p [pid]
- macOS low power mode (which can even be enabled when plugged in)
- VM with limited CPU and RAM, and shared filesystem with host OS.
- Buy older laptop (not an option at this point, really)
- Stress the machine by compiling the Rust compiler in parallel :)
It is indeed possible to constrain a process to the Icestorm cores using taskpolicy:
> taskpolicy -b -p 567
where 567 needs to be replaced by the process id.
Reference: https://eclecticlight.co/2022/10/20/making-the-most-of-apple...
A throttled high-end machine will not behave like a low-end machine. Sure, they'll superficially both be slow, but not slow in the same way. There are differences in IOPS, cache sizes, and so forth you simply can't escape from.
Especially in low-end laptops, you may also have uneven performance from thermal throttling.
version: '3.9'
services:
some-container:
deploy:
resources:
limits:
cpus: '0.5'
memory: 1.5G
reservations:
cpus: '0.5'
memory: 1.5G
Reference: https://docs.docker.com/compose/compose-file/deploy/#resourc...
Geekbench scores with normal and low power mode
- Single core Normal/low power - 1749/1053
- Multi core - 7739/4491
https://www.reddit.com/r/MacOS/comments/qj13bv/m1_macbook_ai...
I sometimes use a remote desktop tool (eg. teamviewer) to troubleshoot my software running on a users machine (with the user on the phone normally).
It's usually the quickest way to understand what issue a user is having, and the user walks away thinking they're getting great customer service.
It could be a good way to get a rough feeling for which areas of your software perform well/badly on a low end machine. One benefit is you get to experience it the way a user does - so the interactions with a 7 year old copy of norton antivirus, one of 13 programs running at once with 1GB of RAM, the fact the user has an always-on-top program that is blocking some of the UI but they don't know how to move it, etc.