AppleScriptRunner causes high CPU, log warnings every few ms

BTT is using lots of CPU (11%). When I look at Console.app, I see thousands of instances of
BetterTouchToolScriptRunner: "AppleEvents: received mach msg which wasn't complex type as expected in getMemoryReference.", roughly every ~10ms.

I have 8 TouchBar AppleScript Widgets that poll every few seconds (checking Spotify, etc; my preset is forked from @goldenchaos). When I disable all the AppleScript Widgets, the CPU usage and the logging go away.

Device information:

  • Type of Mac: 15" 2018
  • macOS version: 10.13.6
  • BetterTouchTool version: 2.6.05

If this turns out to be a widget issue, I'll make sure to back-port the fix to my preset :slightly_smiling_face: I've also been seeing similar CPU usage but haven't been able to identify the issue yet. But maybe that's because it's not an issue with the widgets?

Can you share a screenshot of your BTT Touch Bar preferences?

My Touch Bar settings:

One of the Widgets:


Update: I re-enabled my widgets one by one while watching Activity Monitor. After re-enabling them all, I'm still seeing the console messages but the CPU seems to be behaving fine.

BetterTouchTool varies between 1% and 6%, and BetterTouchToolScriptRunner and BetterTouchToolAppleScriptRunner are floating around 0.5% - 1.5% (mostly on the low end).

The log messages are normal, it's a bug in macOS 10.13.4-6 but fixed in the Mojave beta. Unfortunately I don't know of a way to prevent them. (it's possible to automatically delete them, but shouldn't be necessary)

There is not much you can do to significantly reducing cpu usage, unfortunately running Apple Scripts repeatedly can be quite bad. The only thing that really reduces it, is increasing the update interval.

Do you have the 6 core i7 or i9 CPU? (in that case the CPU usage display is a bit higher due to how it's calculated).

I have the 2.9GHz i9.

I'll keep an eye out to see if I can reproduce the high CPU usage; if I do what logs/debugging would be useful? I'd assumed that the CPU was related to the ScriptRunner because that's what I'd seen in the logs, but this may be an independent (and duplicate?) issue, since I didn't see what process was causing it. And I'm glad to hear that Mojave fixes dumb logging issues. :slight_smile:

The best way would be to sample the problematic process using this terminal command:
sample BetterTouchTool -file ~/Desktop/sample.txt

It's a bit funny how much CPU utilization these 6 core machines show, for example browsing on my old i7 never showed such high CPU values, on my 6 core MBP Chrome and Safari always go above 50% and idle at about 10-15%.
This is because the % value now has 100% per core (and more if Turbo Boost is used). So it can even go higher than 1000% when running stress tests etc. (Running the torture test in Prime95 is funny)

//edit: ah I think it is actually 200% per core because of hyper threading. So the maximum for one process on the 6 core machines should be 1200% :slight_smile:

Depending on what widgets you’re using, it might be possible to convert them to shell scripts or even services (push based). This would dramatically reduce CPU and energy usage.

Aside: I’m planning on releasing my test results regarding AppleScript widgets and battery life in the next day or so.

1 Like

I can't wait to see your results! Where are you going to post them?

How can BTT integrate with services? I'd love to stop polling every seconds for just to trigger external state changes...

I published a set of open source control strip widgets that use event-driven services as models here: https://community.folivora.ai/t/a-standard-set-of-responsive-energy-efficient-widgets-volume-brightness-calendar-timer-world-clock-git/3083/

My project separates things into a MVC pattern for easier testing and configuration. However, if you want to combine models and controllers, another person wrote a simple timer that pushes appearance updates directly from a service: GitHub - iOliverNguyen/tomato: Tomato is a command for running pomodoro in background. It's designed mainly to stay in MacBook touchbar.

It’ll be to this community forum, but I can link to it in this thread once it’s ready.

Here are the preliminary battery life results:

1 Like