Privileged script walking untrusted DOM 70% slower than untrusted doc walking itself

NEW
Unassigned

Status

()

13 years ago
3 years ago

People

(Reporter: hsivonen, Unassigned)

Tracking

({perf})

Trunk
PowerPC
macOS
Points:
---
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(6 attachments)

(Reporter)

Description

13 years ago
Build ID: Firefox trunk checked out on 2006-05-23.

Steps to reproduce, baseline:
1) Load http://hsivonen.iki.fi/test/dom-walk-perf.html
(The script will time itself and alert the time in milliseconds.)

Steps to reproduce, iframe:
1) Load the attached HTML test case. Save it to disk .
2) Load the test case from disk.
3) Paste the URL http://hsivonen.iki.fi/test/dom-walk-perf.html into the text field.
4) Move the focus out of the text field.
5) Wait until the document has loaded into the iframe.
6) Dismiss the alert created by the page itself.
7) Press the button that says Test.
8) Grant universal XPConnect access.
(The script will time itself and alert the time in milliseconds.)

Steps to reproduce, chrome:
1) Apply the attached patch & rebuild Firefox & run with -console and dump() enabled.
2) Load http://hsivonen.iki.fi/test/dom-walk-perf.html in the patched build.
3) Press accel-0.
(The script will time itself and dump() the time in milliseconds.)

Expected results:
Expected the iframe and chrome cases to run as fast as the baseline case.

Actual results:
The iframe and chrome cases took 70% more time than the baseline case.
(Reporter)

Comment 1

13 years ago
Created attachment 223944 [details] [diff] [review]
The patch for the chrome test case
(Reporter)

Comment 2

13 years ago
Created attachment 223945 [details]
The HTML doc for the iframe test case
Created attachment 224018 [details]
Zipped-up version of the big HTML file being used to test
Created attachment 224061 [details]
Zipped-up profle of the same-origin testcase
Created attachment 224063 [details]
Zipped-up profile of iframe testcase

The key difference here is that for the same-origin testcase there are 199 hits under nsScriptSecurityManager::CheckSameOriginDOMProp while for this testcase there are 76420.  That makes some sense -- the same-file testcase just does pointer equality, while the iframe testcase has to:

1)  Check whether the two principals are same-origin and discover that they are
    not (common case would be that they are same-origin).
2)  Check whether the relevant capability is enabled.

Step 1 will get somewhat faster if we fix bug 332182, since that GetOrigin() call is a good bit of that time. Step 2 is mostly spent under nsPrincipal::CanEnableCapability.  But that's mostly an artefact of running this code from a page which doesn't have a signed cert.  This case could be sped up if it's really needed, I suppose...  But the signed cert case should be much faster already.

I'll try to test the chrome stuff next.
Created attachment 224072 [details]
Zipped-up profile of chrome testcase

As expected, this has absolutely nothing to do with the iframe testcase.  The slowdown here is entirely due to overhead for XPCNativeWrapper -- under js_Invoke
we spend 17000 more hits under js_Interpret and a bunch of time under XPC_NW_NewResolve and xpc_CloneJSFunction and RewrapIfDeepWrapper and calling into the cloned function and so forth.
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9-
So I think that this is just life: going through wrappers (which have to do security checks, etc) is just slower than not doing it... It'll get even worse if this sort of script ends up doing cross-process access for each call.
Assignee: general → nobody
QA Contact: ian → general
You need to log in before you can comment on or make changes to this bug.