On-demand launching

[Haravikk]

Suggestion Description

Adguard for Safari has surprisingly high memory usage when the app is running, well over 300mb on my macOS 10.15.6 system, which is high for what it does.

This becomes an even bigger problem with multiple user-accounts, each with adblocking enabled, as if AdGuard for Safari is configured to launch at login the RAM usage adds up quickly; it will only two three logged in users to consume over a gigabyte of RAM. My understanding that this may be partly down to the use of some intermediate framework (Electron?). Anything that makes development easier is of course great, but I feel like there must be a way to reduce the typical memory usage.

Proposed Solution

My understanding of the Safari content blocker API is that the app isn't actually necessary once rules have been set, except to update those rules, so it shouldn't matter if the app isn't running 24/7.

So in the short term, the easiest solution would be to somehow launch the main app only when necessary, i.e- when once a day to check for filter updates, or when the user wants to change settings. While this wouldn't actually reduce the app's memory usage when running, it would only consume that memory temporarily while open, closing again at the earliest opportunity.

This would require some changes to the button in Safari to remove the assumption that the app will always be running, i.e- to offer all options anyway, and to try to launch the app to handle them if/when necessary.

I will however freely admit that I'm very unfamiliar with how Safari extensions work and what capabilities that developers have/do not have, if anyone can clarify any issues that might arise then we might be able to find a way around them. I know that extensions can launch their associated app, so the question is whether an extension app has a way to schedule itself to reopen periodically (can they install launch agents?)

Alternatives Considered

The ideal solution would be to massively reduce RAM usage, though this would probably require a rewrite away from any frameworks currently being used, which would involve a lot of work; if the app can be adapted to run only when actually needed, then memory usage won't really be an issue, though it may be worth thinking about anyway.

[ameshkov]

My understanding that this may be partly down to the use of some intermediate framework (Electron?).

This is exactly the reason, and there's really no way we can reduce it without getting rid of Electron.

We're experimenting with Sciter in AdGuard VPN apps and if it fits, we'll migrate AdGuard for Safari as well. It would take time, though.

Also, the situation will be a little better when we start using the native library for AdGuard -> Safari rules conversion instead of the JS code we're using now.

So in the short term, the easiest solution would be to somehow launch the main app only when necessary, i.e- when once a day to check for filter updates, or when the user wants to change settings.

This won't be user-friendly, an Electron app takes too much time to initialize, and launching it every time when the user opens the extension menu in Safari would cause noticeable delays.

All in all, I don't want to hurry with any short-term solutions while there's a chance to implement a normal one :)

[Haravikk]

So in the short term, the easiest solution would be to somehow launch the main app only when necessary, i.e- when once a day to check for filter updates, or when the user wants to change settings.

This won't be user-friendly, an Electron app takes too much time to initialize, and launching it every time when the user opens the extension menu in Safari would cause noticeable delays.

All in all, I don't want to hurry with any short-term solutions while there's a chance to implement a normal one :)

I haven't noticed it being particularly slow to open? I'm not suggesting that full the app open when the extension menu is opened, but only when the user does something where the app is absolutely necessary, such as clicking the settings cog or choosing to report a site, until the user takes such an action, surely the app should not be necessary? Or do you mean the app currently powers the display of that menu? If so, then perhaps a separate process could be used to handle just the extension menu and no more?

If that's not feasible for easy, I'd still prefer to see the option for on-demand launching; it could come with a warning that the menu will be slower to open, but I'd rather that than have a permanently running process when I don't usually open the menu all that often. Usually when I encounter an issue with a page I just reload without content blockers rather than toggling AdGuard on or off for the site; I only do that once I'm sure the site needs blocking disabled all the time.

[ameshkov]

but only when the user does something where the app is absolutely

The problem is that to show the current website status (whether protection is enabled or not) we need to get to the app itself.

I'd still prefer to see the option for on-demand launching; it could come with a warning that the menu will be slower to open, but I'd rather that than have a permanently running process when I don't usually open the menu all that often.

Let's rename this feature request then. Regardless of the memory usage issue, this on-demand launching makes sense by itself.

[ameshkov]

Brief description of the feature request:

1. Implement an "on-demand launching" mode
2. The app registers a scheduled task for filters updates
3. "Safari Icon" extension works independently (it needs to somehow access the app settings)

Migrating to Sciter would involve some really serious refactoring so I think we should keep this feature request in mind when we do it.