4 ms·

Sure, Vivaldi's AdBlocker might not be impacted a lot, but it does not matter because it is terrible anyway and it triggers every "adblock detection script" I'v

Sure, Vivaldi's AdBlocker might not be impacted a lot, but it does not matter because it is terrible anyway and it triggers every "adblock detection script" I've ever seen. While I like rest of the browser it is unusable without customised uBlock Origin. I was hoping some company would fork Chromium before Manifest V3 change and apply patches from mainline as necessary but it seems less and less likely with every day. If Vivaldi manages to patch out Google's changes and keep uBlock working as it is now they will have me as their user until heat death of the universe.

londons_explore 4y ago
I'm familiar with the Chromium codebase, and maintaining the Manifest web request V2 API wouldn't be a tricky patch to maintain. Even if Google rips it all out and the supporting infrastructure, a full rewrite from scratch wouldn't be too tricky. It's just a bunch of RPC calls to the right extension process from the network stack. You'd still have the downsides that Google is trying to get rid of (extensions can delay requests making the browser slow, and extensions aren't multithreaded so all web requests have to be funnelled through a single javascript thread in the extension). But we've lived with those downsides for 10+ years - I think we can keep them.
- tyingq 4y ago
  >extensions can delay requests making the browser slow There's an older UBO wiki post showing, with their default set of rules, the onBeforeRequest() processing adds about 130ms of latency per request on an older i5 machine. It does also show that a less performance focused ad blocker adds around 420ms. https://github.com/gorhill/uBlock/wiki/uBlock-vs.-ABP:-efficiency-compared/66cc4be09eafa020de8f9a4044ff7ed8e8fc4880 https://github.com/gorhill/uBlock/wiki/uBlock-vs.-ABP:-effic... Of course, then you can subtract whatever performance issues loading all those ads would have caused. That math often ends up in favor of the ad blocker, even if it's not a particularly efficient one.
  - londons_explore 4y ago
    0.13 ms per request is loads when you consider a typical web page (facebook homepage) has about 700 requests now, and due to the single-threaded nature of javascript they all need to be processed sequentially. Ie. thats 91 milliseconds seconds of pegging one core, just for one extension, for loading one page. It's also probably an underestimate, because it doesn't include the IPC time within Chrome, which involves at least two context switches, and the associated cache rewarming. Granted, extensions could be better implemented - for example, for URL blocking, there should be a bloom filter for allowing stuff so that the whole list doesn't need to be checked.
  - CodesInChaos 4y ago
    It costs 0.130ms or 130μs, not 130ms.
  - rasz 4y ago
    >onBeforeRequest() processing adds about 130ms of latency per request Sometimes it pays off to do some sanity checks in your head. 130ms is how long it takes for modern CPU to render 50 frames of Overwatch game. Rendering modern FPS is a LOT heavier than looking up URL in a list of 100K rules.

londons_explore 4y ago

I'm familiar with the Chromium codebase, and maintaining the Manifest web request V2 API wouldn't be a tricky patch to maintain. Even if Google rips it all out and the supporting infrastructure, a full rewrite from scratch wouldn't be too tricky. It's just a bunch of RPC calls to the right extension process from the network stack. You'd still have the downsides that Google is trying to get rid of (extensions can delay requests making the browser slow, and extensions aren't multithreaded so all web requests have to be funnelled through a single javascript thread in the extension). But we've lived with those downsides for 10+ years - I think we can keep them.

tyingq 4y ago
>extensions can delay requests making the browser slow There's an older UBO wiki post showing, with their default set of rules, the onBeforeRequest() processing adds about 130ms of latency per request on an older i5 machine. It does also show that a less performance focused ad blocker adds around 420ms. https://github.com/gorhill/uBlock/wiki/uBlock-vs.-ABP:-efficiency-compared/66cc4be09eafa020de8f9a4044ff7ed8e8fc4880 https://github.com/gorhill/uBlock/wiki/uBlock-vs.-ABP:-effic... Of course, then you can subtract whatever performance issues loading all those ads would have caused. That math often ends up in favor of the ad blocker, even if it's not a particularly efficient one.
- londons_explore 4y ago
  0.13 ms per request is loads when you consider a typical web page (facebook homepage) has about 700 requests now, and due to the single-threaded nature of javascript they all need to be processed sequentially. Ie. thats 91 milliseconds seconds of pegging one core, just for one extension, for loading one page. It's also probably an underestimate, because it doesn't include the IPC time within Chrome, which involves at least two context switches, and the associated cache rewarming. Granted, extensions could be better implemented - for example, for URL blocking, there should be a bloom filter for allowing stuff so that the whole list doesn't need to be checked.
- CodesInChaos 4y ago
  It costs 0.130ms or 130μs, not 130ms.
- rasz 4y ago
  >onBeforeRequest() processing adds about 130ms of latency per request Sometimes it pays off to do some sanity checks in your head. 130ms is how long it takes for modern CPU to render 50 frames of Overwatch game. Rendering modern FPS is a LOT heavier than looking up URL in a list of 100K rules.