... how frequently is the condition retested? Once every second?
Is is possible that having dozens of such tests all running at the same time could slow things down? Should I write my own loop that tests every 10 seconds instead?
I understand your rationale. I'm trying to come up with a counter-example, but cannot. However it should be possible to rewrite the macro to "trigger" once per second instead of pausing in some sort of loop. But even so, I doubt if that would make much difference.
It might be worth knowing how exactly the "Reduce CPU usage" works. I thought that I read a post which said that it "tapers off" execution after different durations (1 min, 5 min, etc.)
Before I posted earlier I searched for more info on that without success and then continued on the basis of what should be common sense. But I can't honestly say that @August's idea is without merit until he tries it
He should probably try it with a more computationally heavy operation than a simple math test, perhaps something like this:
And he would probably have to conduct this test over a long period of time, while logging the CPU usage over that time frame. Not easy. But he's an experimenter and a hard worker.
Nothing conclusive (of course, the way this test is set up), but the data seems to indicate that the Pause Until (with reduce CPU usage enabled) slows down evaluation frequency after about 10 seconds of reevaluating the conditions, and then again even more so after about a minute.
Thanks @tiffle, that's what I needed to know. I'll keep that setting on and not worry about it. I only expect to have at most a couple of dozen running at once, waiting for bootup processes to complete.
Test it and see? Maybe with Activity Monitor open as well?
Here's a macro that'll spawn 20 "Pause until..." macros that replicate yours, run the system_profiler shell command, kill all the "Pause until..." macros, run the shell command again. There's a "beep" halfway through if you want to check the KM menu bar item to see the pauses are running (before the beep) or cancelled (after).
So anything from 7 seconds (~15%) slower to > 1 second faster with pauses, suggesting that there's a small slow down but that other background activity is just as important. This is with "Reduce CPU Usage" off and the un-paused shell script done second so it would benefit from any cacheing, so the un-paused section has every advantage.
I suspect that you'll see even less impact in real world use, especially if this is for your startup macro where the pauses will impact CPU use but most of your macro's actions (launching apps) are I/O bound and any CPU use is probably on other cores anyway.