This would help make event object creation faster.

We need a parent for the wrappers to be able to use slim wrappers, an object that's easily reachable from the event object and that remains the same for the lifetime of that object. As for the init methods, which did you have in mind? There's a bunch and I'm not sure all are that important to quickstub.

Does the patch work with those events which are implemented using an inner nsDOMEvent object and forwarding most of the calls to that. For example nsXMLHttpProgressEvent. There are also others which use the same structure, and I believe some extensions do that too.

Yeah, the parent thin was what was worrying me. I don't have good candidates offhand. :( AS for quickstubs, the testcase I saw was using initMouseEvent. In all seriousness, it was a somewhat silly testcases, but most of these microbenchmarks are. :(

(In reply to comment #2) > Does the patch work with those events which are implemented using an inner > nsDOMEvent object and forwarding most of the calls to that. As long as they don't forward QI it should just work, yes. They won't get the benefits. If they do forward QI they might get the benefits, if they forward QI and but deal with nsISupports themselves the offset tables could be wrong I think.

Could we split this to slimwrapper and quickstub bugs?

Filed Bug 519932