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




13 years ago
3 months ago


(Reporter: hsivonen, Unassigned)



Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)




(6 attachments)



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

Steps to reproduce, baseline:
1) Load
(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 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 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.
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.
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
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.