[pythux]

Thank you for the clarification! Do you know how much time is lost between the time a request is handled by the kernel in C++ and the time it would trigger a callback of the web request API? In other words, what is the overhead of the JS API compared to the raw C++ API?

I understand that you are not competing with uBlock. But I’m always a bit sceptical when I read that it’s faster because it’s C++. Since it is not necessarily true and some measurement is needed before being able to reach this conclusion. I understand though that blocking from the network gives some (constant factor?) advantage compared to a JavaScript extension.

[BrendanEich]

I don't have measurements, as noted (others should chime in), but it matters not only in time to get to extension page process or tab process -- C++ in same process vs. JS after C++ across process boundary matters in memory use terms too, direct (allocation) and indirect (cache effects).

I've been doing browsers since JS was super-slow, advocated its use in Mozilla XUL UX back in the day without it being an issue _per se_, watched JITting JS engines make it even less of an issue for such 10Hz or even 60fps deadlines when done right -- but C++ over JS and in same process vs. multiprocess matters for blocking, due in large part to how many requests there are, and how they affect page rendering.

We are benchmarking again now that we have staff, so I'll try to update here if I do get any results. I don't believe we are yet testing vs. uBO+Chrome, though, for the reason given. We are allies.