As we move closer to getting extensions enabled on the beta channel, we
wanted to summarize the current data we have on performance. The 3 sources
we have right now are startup tests, page cycler tests, and script injection
histograms.
Content scripts get injected with a separate "isolated world" javascript
context into pages matching an extensions match patterns, and have direct
access to the DOM of the page but not its javascript context. See our
documentation here for more details. These scripts can be arbitrarily
expensive depending on the code extension developers write, so for our perf
tests we are interested in the minimum cost to setup the isolated world and
run a minimal script. We use an essentially empty content script in startup
and page cycler tests (it just declares and initializes 3 variables with
integer values).
*Startup Tests*
We added 4 tests to the normal startup ones: extension_content_scripts{1,50}
and extension_toolstrip{1,50}. For the content script tests, instead of
loading about:blank we have them load a simple file-url html page with no
script, and have an extension installed that injects either 1 or 50 content
scripts.
The toolstrip tests need to be replaced with browser actions versions, but
they show the startup impact of having an extension with 1 or 50 toolstrips
installed, which for the 1 extension case is about 7% (8ms).
Focusing on the 1 content script case, depending on which perf bot you look
at (XP Dual/Single Core, Vista Dual/Single Core, Linux/Mac), this causes a
12-20% slowdown in startup compared to about:blank (absolute increase of
14-46ms). In a test I did independently of the buildbots comparing against
loading a simple file-url page that did have script, the slowdown with 1
content script was about 3% (around 9ms).
See the graph for XP dual-core here:
http://build.chromium.org/buildbot/perf/xp-release-dual-core/startup/report.html?history=30
*Page Cycler Tests*
Since the page cycler tests take a long time to run, we've only added one
extensions case to 2 of the individual data sets: Moz (relatively simple
pages, less javascript) and MoreJS (more complicated DOM and javascript).
The Moz set runs very quickly, typically something like 40ms per page on a
fast machine. The MoreJS set runs much more slowly, typically something like
190-200ms per page on a fast machine. We use the "_extcs1" suffix on the
test names to denote "extensions with 1 content script".
Time
Moz: 10-17% increase in cycle time (absolute increase of ~4-5ms per page)
MoreJS: 2-4% (absolute increase of ~5-10ms per page, perhaps a little higher
than Moz due to v8 having more garbage to collect?)
<http://build.chromium.org/buildbot/perf/xp-release-dual-core/moz/report.html?history=30>
http://build.chromium.org/buildbot/perf/xp-release-dual-core/moz/report.html?history=30
http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=30
In tests I ran independently of the buildbots, the increase in cycle time
for multiple extensions with 1 content script each was roughly linear in the
number of extensions as we'd expect (adding about 5-10ms per page per
extension).
Memory
There are a lot of memory statistics gathered for page cycler tests, but
I've just focused on renderer peak working set (ws_peak_r):
Moz: 14% increase (absolute ~10MB)
MoreJS: (essentially no increase discernable on graph)
http://build.chromium.org/buildbot/perf/xp-release-dual-core/moz/report.html?history=30&graph=vm_final_r<http://build.chromium.org/buildbot/perf/xp-release-dual-core/moz/report.html?history=20&graph=vm_final_r>
http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=30&graph=ws_peak_r<http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=20&graph=ws_peak_r>
*Content Script Injection Histograms*
We've added histograms to measure aggregate data on the number of content
scripts and css files that get injected into pages, and how long that
process takes, so we can understand how real world extension content scripts
perform. There are two options for when content scripts run, either at
"document_start" (before the document's html/js has been parsed) or
"document_end" (just before onload event fires, the default and most
useful/popular option by far for extension developers). Whether a slow
content script can affect perceived page load time depends a bit on the page
in question; in some informal tests I found many popular pages that didn't
seem to layout until after body onload fired, but some that did.
After you've been browsing for a while with some extensions installed, open
a tab and go to about:histograms/Extensions, and you'll see histograms named
Extensions.Inject{Start,End}_{ScriptCount,CssCount,Time}. The "Start" vs.
"End" part of the name refers to when injection took place, and "Time"
refers to the number of milliseconds that injection took. The most
interesting histogram to look at is typically "Extensions.InjectEnd_Time",
which gives you an idea of how content scripts are affecting page load time.
When running on a decent speed machine (Core 2 Duo 6600 @2.4GZ), I've
typically seen the majority of pages executing content scripts under 50ms,
with only a very small minority (< 0.5%) running over 100ms.
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
