Need even faster js-wrapping of natives

RESOLVED FIXED

Status

()

RESOLVED FIXED
8 years ago
6 months ago

People

(Reporter: bzbarsky, Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.
(Reporter)

Comment 1

8 years ago
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....
(Reporter)

Comment 2

8 years ago
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.
(Reporter)

Comment 4

8 years ago
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?
Flags: needinfo?(bzbarsky)
(Reporter)

Comment 6

6 months ago
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
Flags: needinfo?(bzbarsky)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.