Safari DNR API timing issues

I created a Xcode project to test the DNR updateDynamicRules API performances on Safari (MacOS).

https://github.com/radiolondra/TestUpdateDynamicRules

Following the instructions in the README file, it's possible to test the extension on Chromium and Firefox browsers (on Windows).

The project uses 2 json files containing static rules, enabled by default in the manifest file. These static rules are automatically installed in the browser when the extension is installed.

Using the extension popup it is possible to add/remove just one very simple dynamic rule in the browser, a rule that acts on a predefined test domain (https://iana.org).

What we want to measure is the time it takes for each browser to add/remove that one dynamic rule.

The results for Safari are unacceptable to say the least:

Safari: from 6000 to 8000 MILLISECONDS (6/8 seconds!) <<<<<<<<<

Chrome: from 5 to 6 MILLISECONDS

Firefox: from 5 to 7 MILLISECONDS

Notice the time needed by Safari... It would be a good idea to take a look at this monstrosity. Thanks.

Does this still reproduce in the latest Safari Technology Preview?

My Mac is with the latest version of everything, so YES Also I created a repo on Github to give you the ability to test it by yourself with wathever version of whatever.

Thank you for the sample project! After looking at it some more, I noticed that when you add/remove a dynamic rule - we are also compiling the 60,000 other rules in a.json and b.json.

This is because we convert the DNR rules into the WebKit Content Blocker format (see https://webkit.org/blog/3476/content-blockers-first-look/) and sort everything by priority.

This means that we are waiting until this is done to call your completion handler.

We noticed that if we pare down the rules in a.json and b.json, the updating of the dynamic rules happens instantaneously.

Yes I know, if we don't use a.json and b.json Safari is able to set that one dynamic rule in a few msecs... Bravo!

The 60,000 other rules from files are static, and Safari have already loaded, processed and sorted them at start (extension install time). And this happens without any waiting time. In fact the static rules are used correctly by Safari and do their job.

Why then when asked to load even 1 dynamic rule does it take a biblical time? Does it stupidly reload everything from the beginning?

As you know the use of DNR rules normally involves the use of static and dynamic rules simultaneously and dynamic rules can vary over time (otherwise why call them ‘dynamic’?) and all, I say ALL, existing compatible DNR browsers update them (add/remove via updateDynamicRules api) very quickly (5-7 msecs) except Safari (6-8 seconds). Which is absolutely not acceptable for serious work.

Safari's problem, I suppose, is to throw all the rules (static and dynamic) into the same pot without any ‘cooking’ strategy. Everything is fine as long as nothing has to be added or taken out of the pot. But if I want to add even ‘a clove of garlic’, what does the cook (Safari) do? He takes everything out of the pot again, divides it again by ingredients, adds the new ingredient (the garlic) and throws everything back into the pot... this cook doesn't seem so smart to me.

By the way... What do you suggest?

The question is:

Is there (or will there soon be) a plan to improve the way Safari updates dynamic rules using the updateDynamicRules DNR API, so as to significantly reduce the current time (6/8 seconds) required to update?

Asking is legal, answering is polite

Safari DNR API timing issues
 
 
Q