Opened on 02/09/2018 at 08:09:19 AM
Last modified on 02/09/2018 at 09:14:46 AM
#6372 new change
FilterEngine method invocations take too long
| Reported by: | asmirnov | Assignee: | |
|---|---|---|---|
| Priority: | P3 | Milestone: | |
| Module: | Libadblockplus | Keywords: | |
| Cc: | sergz, jwangenheim, diegocarloslima, fhd | Blocked By: | |
| Blocking: | Platform: | Android | |
| Ready: | no | Confidential: | no |
| Tester: | Unknown | Verified working: | no |
| Review URL(s): | |||
Description (last modified by asmirnov)
Background
We're obviously using some filterEngine methods for ad blocking: GetHostFromURL(), IsDocumentWhitelisted, Matches() etc. in Chromium+ABP integration.
I've added invocations time logging to know how long it takes and sometimes it takes few seconds!
02-09 12:32:59.614 24543-24859 W/chromium: [WARNING:chrome_network_delegate.cc(397)] Adblock: invoking IsDocumentWhitelisted(https://www.google-analytics.com/collect?v=1&_v=j66&a=1716373988&t=pageview&_s=1&dl=https%3A%2F%2Fm.lenta.ru%2F&ul=ru&de=UTF-8&dt=Lenta.ru&sd=32-bit&sr=360x640&vp=360x559&je=0&_u=ACCAgEAB~&jid=1446535111&gjid=2137434587&cid=1332390533.1518156547&tid=UA-18447330-66&_gid=956643543.1518156547&z=2118792885) 02-09 12:33:03.904 24543-24859 W/chromium: [WARNING:chrome_network_delegate.cc(401)] Adblock: document NOT whitelisted https://www.google-analytics.com/collect?v=1&_v=j66&a=1716373988&t=pageview&_s=1&dl=https%3A%2F%2Fm.lenta.ru%2F&ul=ru&de=UTF-8&dt=Lenta.ru&sd=32-bit&sr=360x640&vp=360x559&je=0&_u=ACCAgEAB~&jid=1446535111&gjid=2137434587&cid=1332390533.1518156547&tid=UA-18447330-66&_gid=956643543.1518156547&z=2118792885
02-09 11:59:02.074 30449-30677 W/chromium: [WARNING:chrome_network_delegate.cc(383)] Adblock: extracting host from url https://collector.mediator.media/register/?cid=2819706&url=https%3A%2F%2Fm.e1.ru%2F&ref=&p=2&e=t0 02-09 11:59:06.534 30449-30677 W/chromium: [WARNING:chrome_network_delegate.cc(385)] Adblock: extracted host "collector.mediator.media" from url https://collector.mediator.media/register/?cid=2819706&url=https%3A%2F%2Fm.e1.ru%2F&ref=&p=2&e=t0
02-09 12:20:47.674 24543-24859 W/chromium: [WARNING:chrome_network_delegate.cc(439)] Adblock: Matches() ... 02-09 12:20:56.224 24543-24859 W/chromium: [WARNING:chrome_network_delegate.cc(441)] Adblock: Matches() finished
It means resource loading is blocked and the thread is just blocked. It seems to be fundamental limitation for our current design (JS code < C++ wrapper < Java wrapper) as we bring JS single-threaded nature into multi-threaded by nature applications.
BTW while loading of website a user can go to Settings. In order to show them we do invoke some FilterEngine methods, that due to JS nature are executed in same single thread. So either settings UI (main thread) or resource loading is blocked just because behind the scene it's invoked in the same thread.
What to change
Probably this can be solved by using Emscripten and avoid using JS code.
Attachments (3)
Change History (11)
Changed on 02/09/2018 at 08:10:41 AM by asmirnov
Changed on 02/09/2018 at 08:10:48 AM by asmirnov
Changed on 02/09/2018 at 08:10:59 AM by asmirnov
comment:1 Changed on 02/09/2018 at 08:12:12 AM by asmirnov
- Cc sergz jwangenheim diegocarloslima fhd added
- Description modified (diff)
comment:6 Changed on 02/09/2018 at 08:18:03 AM by asmirnov
comment:7 Changed on 02/09/2018 at 08:55:33 AM by sergz
Are these measurements for release build? When is it measured, e.g. currently it's expected if the JS engine is blocked by parsing of patterns.ini or a downloaded subscription?
Just in case, currently our JS code is not executed in the same single thread, but only one thread can work with the JS engine at the same time. What concerns emscripten, if we start to use corresponding functionality natively compiled in libadblockplus then we will be able to avoid several unnecessary blocks.
comment:8 Changed on 02/09/2018 at 09:14:46 AM by asmirnov
It's release build (using make android_arm). It's measured in random time and JS can be blocked by something.
But assuming libadblockplus is block box one doesn't care how it's designed behind the scene and one should expect reasonable execution time.
I've tested on middle-range device (or even low-range) Samsung Galaxy Note 3, but i think it should not work that long anyway.