Open Bug 412531 Opened 13 years ago Updated 2 years ago
accessing xpcom properties is 2500% slower than local object properties
I don't know if this is bogus or not, maybe it's known and expected. In bug 384370, after native JSON landed i got a clearer picture of where time is spent, and noticed that a surprisingly large amount of time was spent accessing nsINavHistoryResultNode integer properties, such as itemId, dateAdded, lastModified. The attached test is a rough example. The itemId property used in the test: http://mxr.mozilla.org/seamonkey/source/toolkit/components/places/public/nsINavHistoryService.idl#172 impl: http://mxr.mozilla.org/seamonkey/source/toolkit/components/places/src/nsNavHistoryResult.h#241
Summary: accessing xpcom properties is 2500 times slower than local object properties → accessing xpcom properties is 2500% slower than local object properties
JS_LOCK_GC turns up again
fwiw, landing bug 412698 did not have a significant effect here.
removing the c-types dependency. c-types doesn't change the fact that xpconnect is slow and we have a shit-ton of code written against it. ...unless there's a thingy that we can do in xpconnect that utilizes c-types to speed these scenarios up in way that's transparent to callers.
No longer depends on: 505907
We do have quickstubs that could be used in at least some of the cases where the XPConnect overhead is overwhelming.
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.