accessing xpcom properties is 2500% slower than local object properties

REOPENED
Unassigned

Status

()

REOPENED
11 years ago
4 months ago

People

(Reporter: dietrich, Unassigned)

Tracking

({perf})

Trunk
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

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

Comment 1

11 years ago
Created attachment 297273 [details]
simple test
(Reporter)

Updated

11 years ago
Blocks: 384370
Version: unspecified → Trunk
(Reporter)

Updated

11 years ago
Summary: accessing xpcom properties is 2500 times slower than local object properties → accessing xpcom properties is 2500% slower than local object properties

Comment 2

11 years ago
Created attachment 297283 [details]
Shark blame

JS_LOCK_GC turns up again
(Reporter)

Updated

11 years ago
Depends on: 412698
(Reporter)

Comment 3

11 years ago
fwiw, landing bug 412698 did not have a significant effect here.
(Reporter)

Updated

9 years ago
Depends on: 505907
(Reporter)

Comment 4

9 years ago
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.

Comment 6

4 months ago
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
Last Resolved: 4 months ago
Resolution: --- → INACTIVE

Updated

4 months ago
Status: RESOLVED → REOPENED
Resolution: INACTIVE → ---
You need to log in before you can comment on or make changes to this bug.