Open The-Compiler opened 2 years ago
Do you know if the performance has always been this bad for large blocklists, or if it only started happening after the recent 5.2
update? In the latter case, I may have an inkling of what is wrong.
Looks like it takes a similar time on 0.5.0 too for me.
Ah, I think I know why. The underlying adblock
library used to compress the cache file with brotli
, but doesn't do that anymore. I guess I should fix that by compressing with brotli
in python-adblock
. Alternatively, qutebrowser could use serialize
(as opposed to serialize_to_file
), and do its own compression using zlib.
Both would be fine by me. Though from reading https://github.com/brave/adblock-rust/commit/85063aa56c11a8c4d6b7f99abc55d1a9ae4b7002 (which was then reverted in https://github.com/brave/adblock-rust/commit/d61c0e53a798042531429cea39b51e0e78f94a54 it should still be doing gzip compression, no?
Before I explain the issue, let me note that I'm not sure if this is the right place - chances are, the answer is just "don't do that...", or perhaps this is something that can be improved somehow in the adblocking library rather than this wrapper. However, I lack the Rust knowledge to properly report it there, and I'd like to hear your opinion on this first.
Apparently, there have been posts suggesting to add many more filter lists to qutebrowser, namely:
It looks like there are people who blindly copy that, because more clearly must be better or something...
However, running
:adblock-update
with those lists results in aadblock-cache.dat
which is around 130 MB, and qutebrowser hangs about 2-4s at startup with it (when callingself._engine.deserialize_from_file
). Some questions/ideas: