Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need statistics for each filter like in ABP. #983

Closed
antdude opened this issue Nov 27, 2015 · 6 comments
Closed

Need statistics for each filter like in ABP. #983

antdude opened this issue Nov 27, 2015 · 6 comments
Labels

Comments

@antdude
Copy link

antdude commented Nov 27, 2015

In ABP, I could see the detailed statistics on each filter like how many times it was used, last used, etc. I would like to see this in UO as well.

@gorhill
Copy link
Owner

gorhill commented Nov 27, 2015

The rationale for a feature should never ever be "like in ABP" -- uBO is not a clone of ABP.

I consider features according to real and concrete issues in need of a solution for majority of users, not things just "nice to have" for a minority of users.

@lewisje
Copy link

lewisje commented Nov 27, 2015

Also, it should be noted that only the Firefox version of ABP has this feature: It has proven difficult to add it to ABP for other platforms (they were developed separately, not as forks of the Firefox extension).

@LifeIsStrange
Copy link

I think that this feature could be very useful for find a good compromise between performance and blocking ratio.

For exemple I don't know if peter lowe's ad list is useful for me because I mostly see french sites.
This feature could give me an answer.

@gorhill
Copy link
Owner

gorhill commented Dec 6, 2015

The only sensible implementation of this I can think of, is to make it an opt-in feature in the logger. Only those who actually open the logger incur whatever resource overhead it causes. And if on top of this the filter stats are opt-in, this added overhead would be incurred only by those who care to open the logger and opt-in into filter stats.

This means if someone is interested in collating filter stats, one would have to open the logger, enabled filter stats collation, and keep the logger open for as long as filter stats have to be collected.

Just pondering how this could be reasonably implemented, causing zero resource overhead to be added for those who do not care about these stats. I haven't decided whether I want to implement this, and I don't see this implemented in the short term, I consider there are more important things to work on.

@haarp
Copy link

haarp commented Dec 24, 2015

I maintain a bunch of personal filters, both for ads and non-ad purposes. Websites change all the time - I would really appreciate being able to see when a filter was last used, to let me know if one is outdated or not necessary anymore. ABP had this feature and it was quite useful. Even if UO is not ABP, this is something I am sorely missing in UO.

This also necessitates that the statistics are running all the time, not only when the logger is openend. Making it an opt-in would suffice.

@gomoku
Copy link

gomoku commented Aug 16, 2017

I agree with @LifeIsStrange's and @haarp's argumentation and I disagree with gorhill's:

@gorhill : I consider there are more important things to work on.

Maybe at the moment yes, but generally from a design point of view, what you're saying is just strange, because a filter hits stats counter (also with a possibility to manually tick/untick a particual filter by a mouse's click) just like in ADP, is a very important, handy and usefull thing which should have been done long ago, in the first releases of uBlock Origin, and also in every real ad blocker. The argumentation 'why', is the same as @LifeIsStrange's and @haarp's argumentation, and extending theirs point I can add that having xxx thousands filters while 90% of them are not being used and are just unnecessarily slowing down webbrowsing, is not a good idea. It seems logical to gain some hits statistics, and get rid of unnecessary ballast (filters) to improve webbrowsing speed. The filter hits counter stats thing could be turned off by default, and could be a turn on/off feature, so having it disabled wouldn't impact on the speed. Several months ago I've switched from ADP to uBO, because uBO is crazy fast + has a very usefull remove duplicates feature, but if I wanna optimize my filters I still have to switch to ADP to see the hits stats, and then get back to uBO then get rid of unnecessary ballast (filters), which is not comfortable.

Repository owner locked and limited conversation to collaborators Aug 16, 2017
Repository owner unlocked this conversation May 24, 2019
manhhomienbienthuy pushed a commit to manhhomienbienthuy/uBlock that referenced this issue May 28, 2019
Related issue:
- gorhill#983
- gorhill#1353

The current implementation reports statistics for all
static filters, and the presentation/featureset is
intentionally minimal: *Do not open issues about this.*
It's still a work in progress and it will be worked on
slowly and thoughtfully over time and as time allows.

Pausing the logger will not pause the collation of
filter hit statistics, thus it is possible to lower
the logger overhead by pausing logger output without
losing filter hit collation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants