Thanks for doing this. It seems like we should shoot for getting the cost of browser/page actions down to zero, and the cost of content scripts to zero above similar script running in page.
I will create bugs for these two (plus another bug just to create startup tests for browser actions). - a On Tue, Oct 27, 2009 at 9:26 AM, Antony Sargent <[email protected]> wrote: > 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/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/morejs/report.html?history=30&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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
