Proceeding wildcards in rules

[ryanbr]

In Easylist (and Adguard) we'll use, we consider this "optimised" when using wildcard for general block rules with "/ /". Its been like this for the last 15yrs+ for us.

https://github.com/easylist/easylist/blob/master/easylist/easylist_general_block.txt
https://github.com/AdguardTeam/AdguardFilters/blob/master/BaseFilter/sections/general_url.txt

/adsmanager.nsf/*
/cgi-bin/ad/*
/cgi-bin/ads/*

But I've noticed proceeding wildcards in rules Isn't the wildcard redudant here? Seems less optimised.

Should be re-writen:

/ads/autopromo/*$media,xhr,redirect=noopmp3-0.1s,domain=deezer.com

Whats the faster/better method to use in uBO?

[Yuki2718]

IIRC there was a commit to remove such redundant wildcards on compilation.

[garry-ut99]

According to this Wiki article, a wildcard should be placed at the end, and not at the beginning:
https://github.com/gorhill/uBlock/wiki/Filter-Performance#narrowing-options-for-network-filters

But I'm not sure if anything has changed in uBO since the article was updated last time (several months ago),
maybe it doesn't make a difference anymore whether a wildcard is put at the beginning or at the end.

---

Yuki2718 : IIRC there was a commit to remove such redundant wildcards on compilation.

In the previous discussion you said something different:

#23649 (reply in thread) : Yuki2718 : *VtSEHB5XEMg*$all such filters won't be tokenized and affects performance by the numbers of them.

[gorhill]

The purpose of the wildcard is to prevent treating the filter as a regex -- and trailing wildcard is the preferred approach in such case. I don't know why that commit changed this. It makes no difference performance-wise for uBO whether it's at the start of the end, though the syntax highlighter highlights the wildcard differently when it's at the end as it is considered non-superfluous in case of /.../ pattern.

[stephenhawk8054]

@garry-ut99 Yuki was talking about "tokenized" strings, which is different to this discussion (wildcard to prevent regex)

[garry-ut99]

I was aware of such possibility, but I still preferred to ask and make sure what is the context of his comments, instead of guessing what someone did exactly mean by unclear terms as "such redundant wildcards" or "such filters" as both of them describe very similiar filters which have two wildcards: at the begining and at the end.

[garry-ut99]

ryanbr : Would it add the missing wildcard at the end of the string?

Yes, it can be observed in the logger, all of the following example filters are displayed as /something/* (and /some/thing/*) in the logger:

*/something/*
*/something/
/something/*

*/some/thing/*
*/some/thing/
/some/thing/*

(Of course with an assumption and hope that the logger doesn't fool us and is WYSIWYG compilant in that case, which means it displays exactly the same filter that is actually used.)

[ryanbr]

I'll close this since there is a general clarity regarding this.

[garry-ut99]

I'll close this

Don't miss my reply, as you've closed the thread few seconds before I commented.

since there a general clarity regarding this.

Not enought, still more clear with my last reply.