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).
*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?)
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)
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.
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.
On Tue, Oct 27, 2009 at 9:26 AM, Antony Sargent <asarg...@google.com> 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).
> 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?)
> 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)
> 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.
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.
On Tue, Oct 27, 2009 at 7:37 PM, Adam Barth <aba...@chromium.org> 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 <asarg...@google.com> 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).
>> 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?)
>> 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)
>> 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.
On Tue, Oct 27, 2009 at 9:52 AM, Anton Muhin <ant...@chromium.org> wrote: > 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.
I suspect you'll see a performance gain on any simple DOM benchmark that runs in the isolated world. That code path is hit on every wrapper lookup.
> Overall there are probably lot of low hanging fruits for isolated > worlds performance, but we need some ways to measure it.
On Tue, Oct 27, 2009 at 8:00 PM, Adam Barth <aba...@chromium.org> wrote: > On Tue, Oct 27, 2009 at 9:52 AM, Anton Muhin <ant...@chromium.org> wrote: >> 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.
> I suspect you'll see a performance gain on any simple DOM benchmark > that runs in the isolated world. That code path is hit on every > wrapper lookup.
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).
On Tue, Oct 27, 2009 at 9:26 AM, Antony Sargent <asarg...@google.com> 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).
> 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?)
> 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)
> 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.
On Tue, Oct 27, 2009 at 8:26 AM, Antony Sargent <asarg...@google.com> wrote: > 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?)
This was done by delaying injection until after page load is complete for fast pages. The heuristic is that we inject at min(DOMContentLoaded + 200ms, onload).
The idea is to not delay fast pages, but not to have to wait too long for injection for slow pages.
We still have work to do on Chrome startup, but I'm hopeful we can fix that, too.
On Tue, Oct 27, 2009 at 8:04 PM, Anton Muhin <ant...@chromium.org> wrote: > On Tue, Oct 27, 2009 at 8:00 PM, Adam Barth <aba...@chromium.org> wrote: >> On Tue, Oct 27, 2009 at 9:52 AM, Anton Muhin <ant...@chromium.org> wrote: >>> 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.
>> I suspect you'll see a performance gain on any simple DOM benchmark >> that runs in the isolated world. That code path is hit on every >> wrapper lookup.
> Could someone either see if it helps or give me instructions how to bench it?
> yours, > anton.
> On Tue, Oct 27, 2009 at 8:04 PM, Anton Muhin <ant...@chromium.org> wrote: >> On Tue, Oct 27, 2009 at 8:00 PM, Adam Barth <aba...@chromium.org> wrote: >>> On Tue, Oct 27, 2009 at 9:52 AM, Anton Muhin <ant...@chromium.org> wrote: >>>> 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.
>>> I suspect you'll see a performance gain on any simple DOM benchmark >>> that runs in the isolated world. That code path is hit on every >>> wrapper lookup.
So, I eventually managed to embed some DOM benchmarks into extension.
The patch I sent (with one fix) buys us roughly 20%, after it
benchmarks ran as a content script lag something like 4% compared to
same benchmarks ran w/o any content script.
I'd appreciate if someone would have look at extensions I wrote to
estimate how representative they are (they required minor tweaks to
benchmarks, changing top to parent due to another embedding):
http://www.corp.google.com/~antonm/extensions/
Overall, I'd suggest to add them to perf buildbots: as of current they
need some massaging to get rid of, e.g., absolute paths, but that
should be doable. Two problems I can immediately see: 1) they take a
notable amount of time, 2) I don't know if it's possible/easy to
install an extension into the test.
On Fri, Nov 6, 2009 at 7:46 AM, Adam Barth <aba...@chromium.org> wrote:
> Try running a DOM benchmark while there is a content script that's
> waiting for a message from a background page.
> Adam
> On Thu, Nov 5, 2009 at 12:12 PM, Anton Muhin <ant...@chromium.org> wrote:
>> Adam, all,
>> Could someone either see if it helps or give me instructions how to bench it?
>> yours,
>> anton.
>> On Tue, Oct 27, 2009 at 8:04 PM, Anton Muhin <ant...@chromium.org> wrote:
>>> On Tue, Oct 27, 2009 at 8:00 PM, Adam Barth <aba...@chromium.org> wrote:
>>>> On Tue, Oct 27, 2009 at 9:52 AM, Anton Muhin <ant...@chromium.org> wrote:
>>>>> 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.
>>>> I suspect you'll see a performance gain on any simple DOM benchmark
>>>> that runs in the isolated world. That code path is hit on every
>>>> wrapper lookup.
>>> Ok, I will try to have a look at it this week.
On Tue, Nov 24, 2009 at 2:42 PM, Anton Muhin <ant...@chromium.org> wrote:
> So, I eventually managed to embed some DOM benchmarks into extension.
> The patch I sent (with one fix) buys us roughly 20%, after it
> benchmarks ran as a content script lag something like 4% compared to
> same benchmarks ran w/o any content script.
> I'd appreciate if someone would have look at extensions I wrote to
> estimate how representative they are (they required minor tweaks to
> benchmarks, changing top to parent due to another embedding):
> http://www.corp.google.com/~antonm/extensions/
> Overall, I'd suggest to add them to perf buildbots: as of current they
> need some massaging to get rid of, e.g., absolute paths, but that
> should be doable. Two problems I can immediately see: 1) they take a
> notable amount of time, 2) I don't know if it's possible/easy to
> install an extension into the test.
> Any comments are most appreciated,
> yours,
> anton.
> On Fri, Nov 6, 2009 at 7:46 AM, Adam Barth <aba...@chromium.org> wrote:
>> Try running a DOM benchmark while there is a content script that's
>> waiting for a message from a background page.
>> Adam
>> On Thu, Nov 5, 2009 at 12:12 PM, Anton Muhin <ant...@chromium.org> wrote:
>>> Adam, all,
>>> Could someone either see if it helps or give me instructions how to bench it?
>>> yours,
>>> anton.
>>> On Tue, Oct 27, 2009 at 8:04 PM, Anton Muhin <ant...@chromium.org> wrote:
>>>> On Tue, Oct 27, 2009 at 8:00 PM, Adam Barth <aba...@chromium.org> wrote:
>>>>> On Tue, Oct 27, 2009 at 9:52 AM, Anton Muhin <ant...@chromium.org> wrote:
>>>>>> 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.
>>>>> I suspect you'll see a performance gain on any simple DOM benchmark
>>>>> that runs in the isolated world. That code path is hit on every
>>>>> wrapper lookup.
>>>> Ok, I will try to have a look at it this week.
|
