Looking at dromaeo profiles, xpc_qsXPCOMObjectToJsval features rather prominently in a lot of the DOM ones (> 20% for any of them). Looking at the actual time breakdown, about 2/3 of the time for this function is spent under XPCConvert::NativeInterface2JSObject. The other third is basically setting up that call: tons of movs from [epb+something] to [esp+something] (all via registers, too!). Similar for setting up the call to xpc_qsXPCOMObjectToJsval to start with; a good bit of time in the original quickstub is spent doing that. Maybe this is all better on x86-64, but on 32-bit it's painful. I'm not sure what we can do to decrease all this overhead, unfortunately.
Created attachment 463584 [details] [diff] [review] Proof of concept Totally not ok to land given the naming, but speeds up the dromaeo first-child test for me by 3% for example....
And I bet if NativeInterface2JSObject took a struct (the same struct as the other method takes, perhaps?) we could do even better.
I think I do some of this in bug 565742.
In that you eliminate some of the args? Yeah... I just wonder whether we should eliminate all of them.
I think we've done enough on wrapping performance to close this?
Yeah, I think so. Certainly the current setup is quite different from what comment 0 talks about and the attached patch tries to mess with.
Status: NEW → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.