Closed Bug 1338942 Opened 8 years ago Closed 8 years ago

Javascript performance issue in a webext's content script or a sandbox

Categories

(Core :: JavaScript Engine, defect)

51 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1334263

People

(Reporter: u287251, Unassigned)

Details

Attachments

(1 file)

Attached file cs-peformance-webext.zip (deleted) —
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 Build ID: 20170127092049 Steps to reproduce: I have observed that the *exact same* javascript code executes three times slower when executed from within a webext content script than when executed directly embedded in a web page. This is also true for the same javascript code executed inside a sandbox (I gather that webext content scripts are executed inside sandboxes). I have created a minimal webext-based extension to demonstrate this: http://www.raymondhill.net/ublock/cs-performance/cs-peformance-webext.zip Also provided as attachment. The extension will execute a snippet of javascript only when visiting this one specific web page: http://www.raymondhill.net/ublock/cs-performance/index.html The exact same code is executed when visiting this other page, but the code is embedded directly in the document (see toward the end of the source): http://www.raymondhill.net/ublock/cs-performance/index-nosandbox.html Those web pages are otherwise identical -- I simply borrowed it from Wikipedia and blanked all secondary resources from it: https://en.wikipedia.org/wiki/List_of_country_calling_codes When you load one or the other page, the time spent to execute the one function call in the benchmarked javascript code will be output at the console. Here are the comparative results on my side: Executed as a webext: ~30ms Executed as embedded in the page: ~8-9ms It is a fairly large web page, good for benchmarking purpose. Mainly, the javascript code in question will collect and visit many DOM nodes on the page and gather data out of them. This code is actual code used in uBlock Origin (hence the name of the function, "surveyPhase1"). I originally observed that the same exact code was executed much slower on Firefox compared to Chromium. All the repro steps also work with Chromium. I have observed that there is no meaningful difference in benchmark results with Chromium like there is with Firefox, the timings of the benchmarked javascript code are roughly equivalent when executed as a content script or as embedded in the web page. I profiled using geckoprofiler, and here are screenshot of the results: Executed as a webext: http://www.raymondhill.net/ublock/cs-performance/cleopatra-slow.png Executed as a embedded: http://www.raymondhill.net/ublock/cs-performance/cleopatra-normal.png I can share the cleopatra profiling data is needed.
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Just to be sure there is no misunderstanding, when I use "sandbox", I have Components.utils.Sandbox() in mind.
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: