Mac: high CPU in trustd/syspolicd/virus scanner when enabled

[jankatins]

I've installed activitywatch on my up to date catalina Mac by downloading the the activitywatch-v0.9.2-macos-x86_64.dmg file, dragging the icon to application and then went to /Application, clicked right->open, answered the security question and got an icon in my tray/menu bar. I also went and added activitywatch to the accessibility security&privacy list.

Unfortunately, now my system has about 60% of an CPU running trustd, syspolicyd and my virus scanner, which is enough to start the fans.

I can trigger this by quitting activitywatch via the menu icon (all processes stop using CPU) and restarting it (all start up again). When I play with the started modules, the CPU load stops when I stop aw-watcher-window and starts again when I enable it. The rest (server and afk) make no problems. When I disable the virus scanner, the load of the virus scanner goes away but trustd/systpolicyd stay on.

The App was installed a few days ago and I noticed the high CPU (by the starting fan) for a few days. This might correlate with a mac os x update? At least I remember a nightly restart at the same time I started noticing the fans.

(started as a comment in ActivityWatch/activitywatch#334 (comment))

[johan-bjareholt]

I don't think there's much point in debugging mac specific issues right now when we are completely rewriting the mac implementation
#40

Still though, trustd seems to have something to do with SSL certificates and syspolicyd apparently does a lot of things regarding keeping track of applications state (gatekeeper, if they are notirized, if they are a "legacy app" etc).

trustd doesn't seem to have any relation to activitywatch as we don't support SSL/HTTPS so I don't see at all why that should be involved in our process.
Regarding syspolicyd I can see why it might to keep track of activitywatch and what it's doing, but it does not make sense that it should use so much CPU resources. Let's start with hoping that the rewrite of the window watcher makes that process happier.

[varenc]

I can confirm I'm also seeing syspolicyd CPU usage spike when ActivityWatch is running... And it stops when ActivityWatch is closed.

Looking at the console log, after opening ActivityWatch syspolicyd emits a bunch of these log messages:

It later emits a lot of other messages too, but those are first and are the only ones typed "error".

ActivityWatch works and has all the correct permissions. No idea why ActivityWatch is causing this. Guess I'll have to hold tight for the updated Mac release.

[iloveitaly]

I'm seeing this and high memory usage. I think it has to do with using AppleScript calls on a frequent basis. Whether or not they are shelled out to a separate process, they create pretty high memory usage.

I believe #49 will be the ultimate solution here.

[ErikBjare]

This should be fixed with the new default window strategy (implemented in Swift), released in v0.12.1 just an hour ago.

Closing.