412531 - accessing xpcom properties is 2500% slower than local object properties

Status: REOPENED

(Core :: XPConnect, defect)

Description

[Dietrich Ayala (:dietrich)]

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

Comment 1

[Dietrich Ayala (:dietrich)]

Attachment: simple test

Comment 2

[Robert Sayre]

Attachment: Shark blame

JS_LOCK_GC turns up again

Comment 3

[Dietrich Ayala (:dietrich)]

fwiw, landing bug 412698 did not have a significant effect here.

Comment 4

[Dietrich Ayala (:dietrich)]

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.

Comment 5

[Johnny Stenback (:jst)]

We do have quickstubs that could be used in at least some of the cases where the XPConnect overhead is overwhelming.

Comment 6

[BMO Automation]

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.