In Shark, I looked at a test with a big delta, date-format-tofte, and found that the difference is almost entirely due to Principal checks in the browser. Functions like js_ComputeThis, JS_EvalFramePrincipals, and js_CheckPrincipalsAccess are expensive in the browser and basically free in the shell. For example, one js_ComputeThis call site in js_Invoke is 0% in the shell (as ComputeThis), but 8.1% in the browser, where it does some slow XPConnect stuff.
Er... yes. js_ComputeThis is a known browser perf problem; this is why I was pretty excited by mrbkap and jorendorff talking about killing it off. Then again, last I checked it wasn't obviously entirely gated on the security check. Maybe I didn't dig down enough. Are you just seeing nsScriptSecurityManager::CheckObjectAccess taking up all the time?
See bug 515496.
(In reply to comment #1) > Er... yes. js_ComputeThis is a known browser perf problem; this is why I was > pretty excited by mrbkap and jorendorff talking about killing it off. Yeah, it is about 15-30x too slow at the moment, I'd say. > Then > again, last I checked it wasn't obviously entirely gated on the security check. I'll attach Shark's notion of what it's up to. I'm also a little confused by the comment above the call to js_ComputeThis: 1208 * We must call js_ComputeThis in case we are not called from the 1209 * interpreter, where a prior bytecode has computed an appropriate 1210 * |this| already. In this case, we are called from the interpreter. Does this mean we could refactor js_Invoke to skip this check? Or, maybe "called from the interpreter" means something other than "called from js_Interpret".
Oh, XPC_WN_JSOp_ThisObject. That does suck. :( Blake, will bug 515496 in fact address that?
Yes, it should.