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)
Tracking
()
RESOLVED
DUPLICATE
of bug 1334263
People
(Reporter: u287251, Unassigned)
Details
Attachments
(1 file)
(deleted),
application/zip
|
Details |
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.
Just to be sure there is no misunderstanding, when I use "sandbox", I have Components.utils.Sandbox() in mind.
Updated•8 years ago
|
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.
Description
•