diff options
| author | mpcomplete@chromium.org <mpcomplete@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-03-08 21:29:48 +0000 |
|---|---|---|
| committer | mpcomplete@chromium.org <mpcomplete@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-03-08 21:29:48 +0000 |
| commit | 05cc4e799b897a440333d3dbe6d18b904a49759f (patch) | |
| tree | 28d5c1a1aed5c8d0a9648c7e19e595c96c49c0db /chrome/chrome_dll.gypi | |
| parent | b10392939246b06c48eb5debc961839591ebe72a (diff) | |
| download | chromium_src-05cc4e799b897a440333d3dbe6d18b904a49759f.zip chromium_src-05cc4e799b897a440333d3dbe6d18b904a49759f.tar.gz chromium_src-05cc4e799b897a440333d3dbe6d18b904a49759f.tar.bz2 | |
Implement blocking for webRequest.onBeforeRequest extension event.
I did some measurements with a Release build of chrome, both manually and via the page cycler tests. It seems that a simple empty blocking event listener can add anywhere from a 1 to 30ms delay to request times, largely depending on how many requests are in the queue (when many requests come at once, the last ones to be processed by the extension are delayed the longest).
From page cycler data (on my local machine), the average increase in page load time seems to be around 6ms. This is independent of total page load time (which makes sense).
BUG=60101
TEST=covered by apitests
Review URL: http://codereview.chromium.org/6574049
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@77339 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/chrome_dll.gypi')
0 files changed, 0 insertions, 0 deletions