It may be slightly more performant but it's hard to tell by how much. Querying the dock is always expensive.
The problem in your script is that update_touch_bar_widget appName text badgeNumber will completely replace the widget's displayed text.
Honestly I think this widget is something I'd need to do natively to make it somehow performant (even then it needs to send the same calls, but at least it can do it directly via the Accessibility API).
How difficult would it be to implement natively? If it were implemented, would it be something like a "get single dock item and badge value" widget? If this is something you think you could add I won't bother refactoring all this and just update it when you add the native implementation 
Yes something like that.
I don't know yet whether it will be performant enough, but I'll check. It will however not be in the next release.
But you should definitely remove the current implementation, there are now like 30 or more widgets which run a Apple Script every second, so >= 30 Apple Script calls per second. MacOS just doesn't handle that well enough 
You could leave them in "optionally", activating a few of them won't hurt. Maybe make them run only every few seconds. It's just the massive amount of script calls that causes the CPU spikes.
//edit ah, but I think the current implementation in BTT let's scripts run even if they are not visible (there was some use case for that). So leaving them in you'd need to set the update interval to 0...
Holy crap, it runs scripts even when not visible?! That explains a LOT. Like why disabling them doesn't do anything for performance.
Honestly if you just released an update that did not run scripts that are not visible, I feel like it would make a huge difference - I also feel like that's the expected behavior (I certainly thought so). Many scripts are not visible by default, and my intention was to save on performance while offering additional customization options. And this way I could include these sorts of experimental implementations without crippling peoples' systems, haha.
Will spend some time today fine-tuning the dock script frequencies to see if I can get something that doesn't make my Mac hot enough to stir fry with and make an acceptable default set of enabled badges.
I'm actually not quite sure if they run while hidden - will check that in a minute. Maybe I already changed that a while ago
//edit: ok no, they do not run when not visible. (Tested with do shell script "say \"Run!\"")
I'll have a new version with a default dock set shortly. I think I've got things slightly better, gonna fiddle some more... thanks for checking that visibility setting
Btw. it looks like these three are real performance killers:
The system events process CPU usage goes up 30% when activating them.
It seems like
tell application "System Events"
set frontmostApp to name of application processes whose frontmost is true
-- return frontmostApp
end tell
is really expensive.
I'm already working on "Application Groups" that can be added to the list of apps in BTT, this will make it possible to have BTT triggers defined for a specific set of apps. However this is still about two weeks away.
For now maybe I can add a function that passes the frontmost app to the apple script, so you could remove that check. I'll look into that.
Honestly, I've been considering removing the frontmost app detection part of that script - it's just got so much jankiness that it's more distracting than useful, plus a ridiculous number of apps support refresh. I've been thinking about actually reverting it back to the previous behavior where the refresh button shows up whenever a browser is open instead of just frontmost, and this performance info just sealed the deal for me.
I don't even know where to start. I just spend the last 10 minutes of my life reading through all the comments since my last install. And with each comment and each update, I get happier and happier.
You've done an excellent job with this and it's truly remarkable. Thank you so much for your time and dedication to this project.
icalBuddy has been repeatedly crashing, causing CrashReporter to be constantly running and taking up to 80% of my CPU usage and raising my 13" MBP 2018 temps to the 80s. After repeated uninstalls and re-installs, nothing changed so I just decided to uninstall icalBuddy for good. Maybe this has something to do with the new Mojave beta, but will there be a way to integrate Fantastical support without icalBuddy in the future? Also, thanks for the tremendous amount of hard work you've put into this amazing preset!
PS: I did notice that the Franz symbol is missing from the script. The correct badge number shows, but there is no logo on the icon.
The Franz symbol missing has to do with the way BTT stores icons right now, which is buggy. This means that when BTT restarts (which is often), many icons might just disappear, including dock widget icons. Once a BTT alpha is out that fixes the issue, reimport the preset to get the icons back.
I'm not having any issues with icalBuddy on my machine, but @Andreas_Hegenberg said earlier in the thread that he's going to look into adding native calendar and reminders support after the next stable BTT release is out
Would it be possible to add Firefox to the controls?
Sadly it is not, I already tried 
Firefox is apparently notorious for having no scripting support whatsoever, and I can confirm this. However, if that ever changes I'll definitely add FF support. But... don't get your hopes up, if they haven't added it by now I don't think they're ever going to.
Ahh ok, thank you for the quick reply and for your work so far
afaik Firefox has scripting support, but it needs to be enabled first (sorry not at home, can look it up tomorrow).
//edit ah it's just accessibility api support and should probably not be enabled: https://support.mozilla.org/en-US/kb/accessibility-services
I think I have found the main reason for the icon issues (besides the Apple bug): some of the icons you are using have more that 20MB because in die situations BTT didn't resize them automatically. The next update tomorrow will resize all the existing icons.
Wow. Wow. Wow.
You aren't kidding. There's a stunning efficiency difference from yesterday. I'm down to 3% utilization at less than 40C with literally no spikes above default processor speed. It so markedly different I had to double check the comparison was valid.
Morning coffee hasn't made it official yet, but I'm calling this version a winner.
Awesome effort @GoldenChaos and @Andreas_Hegenberg!
Would it be possible to integrate copying the spotify link to the clipboard by a long press on the spotify widget?
I found a script from http://chris-miller.org/get-link-to-currently-playing-spotify-track-via-applescript/ that I've assigned to a named trigger already. Would it be possible to integrate in to the preset itself?
Heres the code that works for me:
tell application "Spotify"
set theTrack to name of the current track
set theArtist to artist of the current track
set theAlbum to album of the current track
set track_id to id of current track
end tell
set AppleScript's text item delimiters to ":"
set track_id to third text item of track_id
set AppleScript's text item delimiters to {""}
set realurl to ("http://open.spotify.com/track/" & track_id)
set theString to theTrack & " - " & theArtist & ": " & realurl
set the clipboard to theString
I'll do one better and make a Spotify long-press widget similar to iTunes this was the one feature I didn't know how to implement. Thank you!! Now it can make it in time for the stable release 
Awesome! That sounds so awesome, the one thing that I couldn't figure out how to do that would be killer for me would being able to like/star/save a track in spotify.
The "starred" attribute(?) on the current track for the spotify applescript integration returns an error on spotify's side it seems. But if you could get that working I would be so so happy! I would love to donate once I scrape up enough money
-- A broke college student