Are there "snail" filters in uBlock?

[Gitoffthelawn]

In ABE/ABP, there is the notion of "snail" filters. When creating a filter, you have to be cognizant to not create a "snail" filter, because they are not processed with the same efficiency as other filters.

Is the same true for uBlock, or by design, does it get around that whole mess?

If it is true for uBlock, how are the slower filters indicated in the UI? ABE/ABP uses a snail icon.

[lewisje]

I think it's something specific to the UI in ABP for Firefox (unless the Chrome extension was recently updated to point out filters likely to be slow), and I know that it uses heuristics that don't exactly match with what makes a filter slow.

Anyway, my guess is that there are filters that are slow for uBlock to process, and that they are mostly the same filters that are slow for ABP to process, but it doesn't indicate this in its UI.

[Gitoffthelawn]

Thanks. I haven't been able to find comprehensive documentation about ABE/ABP snail filters, but from what I've researched, it sounds like ABE/ABP creates 3-byte tokens from all rules, and that for a token to be created it must be delimited by special characters, which are often carets or forward-slashes. (I haven't been able to find a list of all the delimiters, or if ABE/ABP needs the same delimiter on both sides of a token). I'm not sure why ABE/ABP don't use EOL as a delimiter, but they don't seem to.

If filter component strings are too short, or are not properly delimited, then the filter will be much slower than other filters for ABE/ABP to process.

Thus, if uBlock uses a similar tokenization algorithm as ABE/ABP, then it will certainly have the same issue. If it doesn't use the same algorithm, or has implemented a way to get around the aforementioned issue, then it won't have it.

If someone has looked closely at the uBlock algorithm, hopefully they will post here as to whether or not uBlock has the same issue.

[gwarser]

Its best to avoid regex filters. They are slow in general. Some filters can be misinterpreted as regexes. For example /ads/ is a valid path and valid regex because of enclosing slashes. Adding trailing * will fix parsing and this string will be interpreted as simple filter.

[Gitoffthelawn]

That's the best explanation I've ever read for why it sometimes makes sense to add a trailing * to a filter!

Is the "best to avoid" regex true for uBlock as well as ABE/ABP? I'm assuming it is (based on your post), but I want to confirm.

When a regex is used, the underlying uBlock javascript must perform a regex match. When no regex is specified, does uBlock perform a token lookup (like ABE/ABP), or is it a wildcard match?