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)


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: [] Adblock: invoking IsDocumentWhitelisted(
02-09 12:33:03.904 24543-24859 W/chromium: [] Adblock: document NOT whitelisted
02-09 11:59:02.074 30449-30677 W/chromium: [] Adblock: extracting host from url
02-09 11:59:06.534 30449-30677 W/chromium: [] Adblock: extracted host "" from url
02-09 12:20:47.674 24543-24859 W/chromium: [] Adblock: Matches() ...
02-09 12:20:56.224 24543-24859 W/chromium: [] 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) (3.1 KB) - added by asmirnov on 02/09/2018 at 08:10:41 AM.
GetHostFromURL.txt (2.8 KB) - added by asmirnov on 02/09/2018 at 08:10:48 AM.
matches.txt (2.2 KB) - added by asmirnov on 02/09/2018 at 08:10:59 AM.

Download all attachments as: .zip

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:2 Changed on 02/09/2018 at 08:13:58 AM by asmirnov

  • Description modified (diff)

comment:3 Changed on 02/09/2018 at 08:14:11 AM by asmirnov

  • Description modified (diff)

comment:4 Changed on 02/09/2018 at 08:14:52 AM by asmirnov

  • Description modified (diff)

comment:5 Changed on 02/09/2018 at 08:15:55 AM by asmirnov

  • Description modified (diff)

comment:6 Changed on 02/09/2018 at 08:18:03 AM by asmirnov

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.

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.

Add Comment

Modify Ticket

Change Properties
as new .
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from (none).
Next status will be 'reviewing'.
Note: See TracTickets for help on using tickets.