Adam, if we're sure accessing hidden property is a bottleneck, it should be easily solvable: for long time I was toying idea to compile this code into native, but didn't see compelling enough reason to do that. The easy way to measure it would be to hack stuff a bit and put data as in internal field or just add another getter to context. If you like, I can try to do something like that, but I need a simplistic benchmark to estimate performance gain.
Overall there are probably lot of low hanging fruits for isolated worlds performance, but we need some ways to measure it. yours, anton. On Tue, Oct 27, 2009 at 7:37 PM, Adam Barth <[email protected]> wrote: > > In creating isolated worlds, I optimized the performance for the "no > content script" case. I suspect there's room for improvement in the > "one or more content script" case. For example, the current way we > figure out that we're running in an isolated world is slow because we > do a V8 HiddenProperty lookup. If V8 provided a C++ API for caching > the world pointer on a context, I suspect that would gain some amount > of performance. > > Adam > > > 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 -~----------~----~----~----~------~----~------~--~---
