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

Expand bidi-trie code to hold more types of filters #761

Closed
gorhill opened this issue Oct 20, 2019 · 1 comment
Closed

Expand bidi-trie code to hold more types of filters #761

gorhill opened this issue Oct 20, 2019 · 1 comment
Labels
fixed issue has been addressed

Comments

@gorhill
Copy link
Member

gorhill commented Oct 20, 2019

Related issue:

The current bidi-trie code can hold filters which are plain pattern, i.e. no wildcard characters, and which have no origin option (i.e. domain=), right or left anchor, and neither a csp= option.

Examples of filter that can be moved into a bidi-trie data structure:

&ad_box_
/w/d/capu.php?z=$script,third-party
||liveonlinetv247.com/images/muvixx-150x50-watch-now-in-hd-play-btn.gif

Examples of filters that cannot be moved to a bidi-trie:

-adap.$domain=~l-adap.org
/tsc.php?*&ses=
||ibsrv.net/*forumsponsor$domain=[...]
@@||imgspice.com/jquery.cookie.js|$script
||view.atdmt.com^*/iview/$third-party
||postimg.cc/image/$csp=[...]

Ideally the filters above should be able to be moved to a bidi-trie since they are basically plain patterns, or at least partially moved to a bidi-trie when there is only a single wildcard (i.e. made of two plain patterns).

Also, currently there are two distinct bidi-tries in which plain-pattern filters can be moved to: one for patterns without hostname anchoring and another one for patterns with hostname-anchoring. This is currently required because the hostname-anchored patterns have an extra condition which is outside the bidi-trie knowledge. Ideally there should be only one bidi-trie for both filters.

This issue is to track the work on this.

@uBlock-user uBlock-user added the TODO todo label Oct 20, 2019
@gorhill
Copy link
Member Author

gorhill commented Oct 20, 2019

Stats comparing before/after for top 25 buckets, from most populous to least populous. For the before: stats, the trie= figure is the sum of the two tries that were used, while there is a single figure for after: since there is now only one trie per bucket. The array= figure is the number of filters which can't be put in a trie and which must be iterated when there is no match against the trie. Some buckets are not present in either before: or after:: this is because the token picking code has been changed -- the "bad tokens" are now programmatically generated.

bits: 0, token: cf
- before: size=940   trie=911+9  array=20
-  after: size=1030  trie=1027   array= 3

bits: 0, token: cee
- before:  size=649  trie=641+0  array=8
-  after:  size=770  trie=769    array=1

bits: 41, token: 1a29ee9
- before:  size=253  trie=0+231  array=22
-  after:  size=253  trie=251    array=2

bits: 0, token: d9d55e4
- before:  size=211  trie=174+10  array=27
-  after:  size=235  trie=232     array=3

bits: 0, token: 1edcf759
- before:  size=163  trie=154+0  array=9
-  after:  size=178  trie=176    array=2

bits: 0, token: cd1
- before:  size=122  trie=118+0  array=4
-  after:  size=142  trie=142    array=0

bits: 41, token: 158dee6
- before:  size=121  trie=0+0  array=121
-  after:  ?

bits: 41, token: 1ee76acf
- before:  ?
-  after:  size=116  trie=116  array=0

bits: 0, token: cd01ce4
- before:  size=104  trie=86+0  array=18
-  after:  size=104  trie=104   array=0

bits: 0, token: 1edcf6
- before:  size=100  trie=88+0  array=12
-  after:  size=106  trie=105   array=1

bits: 0, token: f34
- before:  ?
-  after:  size=96  trie=95  array=1

bits: 8, token: e80c60e
- before:  size=96  trie=0+54  array=42
-  after:  size=96  trie=95    array=1

bits: 0, token: ee9
- before:  size=88  trie=8+9  array=71
-  after:  ?

bits: 0, token: 1ffdee
- before:  size=84  trie=80+0  array=4
-  after:  size=95  trie=94    array=1

bits: 0, token: 16b2
- before:  size=74  trie=65+0  array=9
-  after:  size=83  trie=80    array=3

bits: 40, token: 1bd30cf3
- before:  size=80  trie=0+0  array=80
-  after:  size=80  trie=75   array=5

bits: 0, token: dd881d
- before:  size=76  trie=75+0  array=1
-  after:  size=77  trie=77    array=0

bits: 0, token: 1fab8fbd
- before:  size=73  trie=70+0  array=3
-  after:  size=77  trie=77    array=0

bits: 0, token: 12c
- before:  size=71  trie=66+0  array=5
-  after:  size=76  trie=76    array=0

bits: 0, token: 1edcf71d
- before:  size=68  trie=63+0  array=5
-  after:  size=71  trie=71    array=0

bits: 0, token: 1351
- before:  size=70  trie=62+0  array=8
-  after:  ?

bits: 0, token: 13bb360c
- before:  size=73  trie=64+0  array=9
-  after:  size=69  trie=69    array=0

bits: 0, token: f680e0d
- before:  size=66  trie=0+45  array=21
-  after:  size=66  trie=64    array=2

bits: 0, token: 1a6217
- before:  size=53  trie=46+0  array=7
-  after:  size=53  trie=55    array=1

bits: 0, token: d00564c
- before:  size=52  trie=48+0  array=4
-  after:  size=54  trie=54    array=0

bits: 0, token: d8e4b9c
- before:  size=51  trie=0+30  array=21
-  after:  size=51  trie=50    array=1

bits: 41, token: ee84e
- before:  ?
-  after:  size=49  trie=39     array=10

(all the comments I add here are meant to be used in the commit message, hence why I am verbose).

gorhill added a commit to gorhill/uBlock that referenced this issue Oct 21, 2019
Related issues:
- uBlockOrigin/uBlock-issues#761
- uBlockOrigin/uBlock-issues#528

The previous bidi-trie code could only hold filters which
are plain pattern, i.e. no wildcard characters, and which
had no origin option (`domain=`), right and/or left anchor,
and no `csp=` option.

Example of filters that could be moved into a bidi-trie
data structure:

    &ad_box_
    /w/d/capu.php?z=$script,third-party
    ||liveonlinetv247.com/images/muvixx-150x50-watch-now-in-hd-play-btn.gif

Examples of filters that could NOT be moved to a bidi-trie:

    -adap.$domain=~l-adap.org
    /tsc.php?*&ses=
    ||ibsrv.net/*forumsponsor$domain=[...]
    @@||imgspice.com/jquery.cookie.js|$script
    ||view.atdmt.com^*/iview/$third-party
    ||postimg.cc/image/$csp=[...]

Ideally the filters above should be able to be moved to a
bidi-trie since they are basically plain patterns, or at
least partially moved to a bidi-trie when there is only a
single wildcard (i.e. made of two plain patterns).

Also, there were two distinct bidi-tries in which
plain-pattern filters can be moved to: one for patterns
without hostname anchoring and another one for patterns
with hostname-anchoring. This was required because the
hostname-anchored patterns have an extra condition which
is outside the bidi-trie knowledge.

This commit expands the number of filters which can be
stored in the bidi-trie, and also remove the need to
use two distinct bidi-tries.

- Added ability to associate a pattern with an integer
  in the bidi-trie [1].
    - The bidi-trie match code passes this externally
      provided integer when calling an externally
      provided method used for testing extra conditions
      that may be present for a plain pattern found to
      be matching in the bidi-trie.

- Decomposed existing filters into smaller logical units:
    - FilterPlainLeftAnchored =>
        FilterPatternPlain +
        FilterAnchorLeft
    - FilterPlainRightAnchored =>
        FilterPatternPlain +
        FilterAnchorRight
    - FilterExactMatch =>
        FilterPatternPlain +
        FilterAnchorLeft +
        FilterAnchorRight
    - FilterPlainHnAnchored =>
        FilterPatternPlain +
        FilterAnchorHn
    - FilterWildcard1 =>
        FilterPatternPlain + [
          FilterPatternLeft or
          FilterPatternRight
        ]
    - FilterWildcard1HnAnchored =>
        FilterPatternPlain + [
          FilterPatternLeft or
          FilterPatternRight
        ] +
        FilterAnchorHn
    - FilterGenericHnAnchored =>
        FilterPatternGeneric +
        FilterAnchorHn
    - FilterGenericHnAndRightAnchored =>
        FilterPatternGeneric +
        FilterAnchorRight +
        FilterAnchorHn
    - FilterOriginMixedSet =>
        FilterOriginMissSet +
        FilterOriginHitSet
    - Instances of FilterOrigin[...], FilterDataHolder
      can also be added to a composite filter to
      represent `domain=` and `csp=` options.

- Added a new filter class, FilterComposite, for
  filters which are a combination of two or more
  logical units. A FilterComposite instance is a
  match when *all* filters composing it are a
  match.

Since filters are now encoded into combination of
smaller units, it becomes possible to extract the
FilterPatternPlain component and store it in the
bidi-trie, and use the integer as a handle for the
remaining extra conditions, if any.

Since a single pattern in the bidi-trie may be a
component for different filters, the associated
integer points to a sequence of extra conditions,
and a match occurs as soon as one of the extra
conditions (which may itself be a sequence of
conditions) is fulfilled.

Decomposing filters which are currently single
instance into sequences of smaller logical filters
means increasing the storage and CPU overhead when
evaluating such filters. The CPU overhead is
compensated by the fact that more filters can now
moved into the bidi-trie, where the first match is
efficiently evaluated. The extra conditions have to
be evaluated if and only if there is a match in the
bidi-trie.

The storage overhead is compensated by the
bidi-trie's intrinsic nature of merging similar
patterns.

Furthermore, the storage overhead is reduced by no
longer using JavaScript array to store collection
of filters (which is what FilterComposite is):
the same technique used in [2] is imported to store
sequences of filters.

A sequence of filters is a sequence of integer pairs
where the first integer is an index to an actual
filter instance stored in a global array of filters
(`filterUnits`), while the second integer is an index
to the next pair in the sequence -- which means all
sequences of filters are encoded in one single array
of integers (`filterSequences` => Uint32Array). As
a result, a sequence of filters can be represented by
one single integer -- an index to the first pair --
regardless of the number of filters in the sequence.

This representation is further leveraged to replace
the use of JavaScript array in FilterBucket [3],
which used a JavaScript array to store collection
of filters. Doing so means there is no more need for
FilterPair [4], which purpose was to be a lightweight
representation when there was only two filters in a
collection.

As a result of the above changes, the map of `token`
(integer)  => filter instance (object) used to
associate tokens to filters or collections of filters
is replaced with a more efficient map of `token`
(integer) to filter unit index (integer) to lookup a
filter object from the global `filterUnits` array.

Another consequence of using one single global
array to store all filter instances means we can reuse
existing instances when a logical filter instance is
parameter-less, which is the case for FilterAnchorLeft,
FilterAnchorRight, FilterAnchorHn, the index to these
single instances is reused where needed.

`urlTokenizer` now stores the character codes of the
scanned URL into a bidi-trie buffer, for reuse when
string matching methods are called.

New method: `tokenHistogram()`, used to generate
histograms of occurrences of token extracted from URLs
in built-in benchmark. The top results of the "miss"
histogram are used as "bad tokens", i.e. tokens to
avoid if possible when compiling filter lists.

All plain pattern strings are now stored in the
bidi-trie memory buffer, regardless of whether they
will be used in the trie proper or not.

Three methods have been added to the bidi-trie to test
stored string against the URL which is also stored in
then bidi-trie.

FilterParser is now instanciated on demand and
released when no longer used.

***

[1] https://github.com/gorhill/uBlock/blob/135a45a878f5b93bc538f822981e3a42b1e9073f/src/js/strie.js#L120
[2] e94024d
[3] https://github.com/gorhill/uBlock/blob/135a45a878f5b93bc538f822981e3a42b1e9073f/src/js/static-net-filtering.js#L1630
[4] https://github.com/gorhill/uBlock/blob/135a45a878f5b93bc538f822981e3a42b1e9073f/src/js/static-net-filtering.js#L1566
gorhill added a commit to gorhill/uBlock that referenced this issue Oct 22, 2019
We need a `matchAll()` method on the bidi-trie before
we can store filters of type `data` in it.

Related issue:
- uBlockOrigin/uBlock-issues#761

Related commit:
- 7971b22
gorhill added a commit to gorhill/uBlock that referenced this issue Oct 26, 2019
Related issue:
- uBlockOrigin/uBlock-issues#761

Changes related to above issue made it possible to
create WASM versions of methods used in the bidi-trie.
In this commit, WASM versions for startsWith(), indexOf()
and lastIndexOf() have been implemented.
gorhill added a commit to gorhill/uBlock that referenced this issue Oct 28, 2019
gorhill added a commit to gorhill/uBlock that referenced this issue Oct 29, 2019
gorhill added a commit to gorhill/uBlock that referenced this issue Oct 31, 2019
@uBlock-user uBlock-user added fixed issue has been addressed and removed TODO todo labels Nov 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fixed issue has been addressed
Projects
None yet
Development

No branches or pull requests

2 participants