Add "Ignore generic cosmetic filters" option

Bushido

Member
Hello,

it is possible to add this option to ad-blocking function to make Adguard more effecient for low powered devices?
I saw that your rival ,,uBlock" had implemented this feature.
Or do you already have this option enabled somwhere in settings?
 

Bushido

Member
It extends battery life for laptops and makes personal computers to use less power. Github user Gorhill came to that conclusion in regards of benchmark tests.
If laptop battery life is longer then less money is spent for replacing/fixing battery during lifetime.
 

avatar

Administrator
Staff member
Administrator
It extends battery life for laptops and makes personal computers to use less power. Github user Gorhill came to that conclusion in regards of benchmark tests.
If laptop battery life is longer then less money is spent for replacing/fixing battery during lifetime.
Raymond is not just a github user, he is ublock author:)

Could you please link these benchmarks?
 

avatar

Administrator
Staff member
Administrator
Ah, so it is "Ignore generic cosmetic filters"! Huh, this is a huge difference, you know.

This is not the first time I see him creating yet another rarely used checkbox which is equivalent to a single filter rule.

Anyway, here is a filter rule which will do it for you:
Code:
@@|http$generichide
Also the "battery life" argument is still weird. Even if we take his argument for granted, let's just do a very simple math.

Average overhead: 500ms per a huge web page.

How many web pages do you open for an hour? Let's take you're a surfing maniac and open 500 different pages, 10 in a minute, and every page is huge. So, by using that rule, you've spent 250 extra CPU seconds on it. Which, in turn, is equivalent to about 10-20mAh. Old laptop battery is about 2500-4000 mAh. So you have saved about 0.2% - 0.8% of the battery.

This just does not make any sense.
 

avatar

Administrator
Staff member
Administrator
@Bushido

I'd like to continue my thought about low performance laptops and such.

We have already faced this low-end devices issue a while ago when we were working on Adguard for Android. Of course, there is a direct link between the number of filter rules applied to a page and the filtering speed. Also low-end Android devices are much slower than even a 10-year old laptop, so performance issues are even more important.

So, back then we have found a solution for this which won't affect filtering quality. If you tried AG browser extension you may have seen an option (disabled by default) to start sending ad filters usage statistics to us. Thanks to users who volunteered and turned that option on, we now know which filter rules are really used and which are either rarely used or completely redundant.

Using this data we have provided special "optimized" filters versions (for instance, the size of an optimized English filter is ~40% of the original). If you use AG browser extension, there is an option to switch to "optimized" filters versions.

So, we may introduce the same switch in AG for Windows/Mac as well. What do you think about this solution?
 

Bushido

Member
@Bushido

I'd like to continue my thought about low performance laptops and such.

We have already faced this low-end devices issue a while ago when we were working on Adguard for Android. Of course, there is a direct link between the number of filter rules applied to a page and the filtering speed. Also low-end Android devices are much slower than even a 10-year old laptop, so performance issues are even more important.

So, back then we have found a solution for this which won't affect filtering quality. If you tried AG browser extension you may have seen an option (disabled by default) to start sending ad filters usage statistics to us. Thanks to users who volunteered and turned that option on, we now know which filter rules are really used and which are either rarely used or completely redundant.

Using this data we have provided special "optimized" filters versions (for instance, the size of an optimized English filter is ~40% of the original). If you use AG browser extension, there is an option to switch to "optimized" filters versions.

So, we may introduce the same switch in AG for Windows/Mac as well. What do you think about this solution?
This thought sounds very good. I have already enabled this option in AG browser extension. If this feature will be enabled in AG for Windows/Mac as well, then all AG users will be equally treated, This will be another bonus to choose AG for Windows/Mac instead of browser extension.
If only AG for Windows/Mac (with all the same extension settings integrated) is running, then browsing speed will be much faster. Because if no extension and only AG service, then less memory is used. Right?

Also, what do you think about this reference:
Also, @@|http$generichide does not prevent the loading in memory of all generic cosmetic filters -- this means they would be all residing into memory, never to be used.
?

Gorhill noted that Adguard (what inject unconditionally all generic cosmetic filters into every page and frames on a page) will benefit more than uBlock similar solutions. Maybe he meant that uBlock uses only memory via extension, but Adguard uses also via service and a separate program.
 
Last edited:

SlowMemory

Beta Tester
Gorhill noted that Adguard (what inject unconditionally all generic cosmetic filters into every page and frames on a page) will benefit more than uBlock similar solutions.
It's a clear misunderstanding about Adguard. Adguard has an algorithm of determining what to inject in frames to speed up browsing.
Also, @@|http$generichide does not prevent the loading in memory of all generic cosmetic filters -- this means they would be all residing into memory, never to be used.
This is a statement about ublock origin. Also, memory is not the main point of a GitHub user gorhill's argument, according to the user its purpose was to save some cpu time running its way of injecting generic hiding rules, which exists only in ublock.

The memory point of view is the only part that make sense in your comparison between Adguard and ublock origin, Easylist's generic hiding rules occupy 303KB (https://github.com/easylist/easylist/blob/master/easylist/easylist_general_hide.txt), so you would save this amount of memory, I don't know whether this is considered as a significant amount. I'd say if you use "EasyList without element hiding" which excludes specific hiding rules(https://github.com/easylist/easylist/blob/master/easylist/easylist_specific_hide.txt) as well, which is 577Kb, you can save even more 880Kb of memory. Again this is not related to cpu running time, nor is the main point.
 
Last edited:

Bushido

Member
Gorhill states now that
This option is likely most useful for Firefox for Android
.
If so, then ignoring generic cosmetic filters is useful mostly with Android mobile phones and Adguard will not benefit this?

Plus, Gorhill has come to this calculation:
If 250 seconds at 100% CPU draws 10-20 mAh, then this would mean in the worst case a 2500 mAh battery can provide 2500 / 20 = 125 chunks of 250 seconds with CPU at 100%, meaning 125 x 250 = 31250 seconds = a CPU at 100% for more than 8 hrs before the battery runs out. Really? (best case would be 4000 / 10 * 250 = 27 hours).
So in conclusion - gain of ignoring generic cosmetic filters is very small?
 

avatar

Administrator
Staff member
Administrator
Also, what do you think about this reference:
Also, @@|http$generichide does not prevent the loading in memory of all generic cosmetic filters -- this means they would be all residing into memory, never to be used.
?
This is true. However I don't think that it is important. CSS filter memory footprint is about 8-9 MB. Without generic CSS rules it is about 5-6MB.

If so, then ignoring generic cosmetic filters is useful mostly with Android mobile phones and Adguard will not benefit this?
We have introduced this option in AG for iOS a while ago and frankly I am not satisfied with the result.

I mean the gain is small and the lack of the filtering quality is pretty huge.
 
Top