Closed Bug 71528 Opened 23 years ago Closed 15 years ago

Should optimize entry order in QI to hit frequent IIDs first

Categories

(Core :: XPCOM, defect, P5)

defect

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: sfraser_bugs, Unassigned)

References

Details

(Keywords: helpwanted, perf)

Attachments

(4 files)

Talking to scc and others, we hit upon a cheap optimization that should reduce 
the amount of time spent doing QueryInterface, and that is to ensure that QI 
implementations test for the frequent IIDs first. I'll attach some code, and some 
test results.
Attached file Raw QI frequency data
The data show, for each QI, how many times the QI was called with a given IID. No 
data is given for whether that IID is matched or not. For example:

QueryInterface at in file: nsSupportsPrimitives.cpp at line: 169
{d79dc970-4a1c-11d3-9890-006008962422}  25
{00000000-0000-0000-c000-000000000046}  9

This QI was called 34 times, 25  with {d79dc970-4a1c-11d3-9890-006008962422}, and 
9 with {00000000-0000-0000-c000-000000000046}

IIDs are printed in a first-found order; they are not sorted in any way.
In the run for which I collected data, I ran the page loading test once through, 
typed in a bugzilla entry textarea, opened composer and typed a bit, opened 
mailnews and loaded 2 IMAP folders, and made a new message then typed.
That data is incomplete for two reasons:
1. Lots of classes don't use the macros:
   <http://lxr.mozilla.org/seamonkey/search?string=%3A%3AQueryInterface>

2. I failed to patch the old-style QI macro.

More data coming...
setting to moz0.9.1
Priority: -- → P3
Target Milestone: --- → mozilla0.9.1
Attached file More complete QI data
The QI data I just attached are more complete. I went through the entire tree, 
searching for QI implementations that don't use the macros, and either macroized 
them, or added hooks to call the instrumentation class. (I didn't change any QIs 
in mailnews). I can't guarantee that I got all the QIs, but I got most of them.

The data were generated as before (once through the page loader, some typing in 
composer, a couple of large IMAP mail folders, messing around in bookmarks 
window).
The latest attachment shows the QIs which happen most frequently (picked 
according to those that show big counts), with most of the IIDs annotated with 
the interface name.

This data should be used as input to re-ordering QIs for maximum performance. At 
first glance, the following QIs could benefit from reordering:

nsGlobalWindow
nsMenuItem/nsMenu (Mac implementations)
nsImageContextAsync (if libpr0n doesn't obsolete it)
nsDocShell/nsWebShell
nsWebShellWindow
Blocks: 71874
Keywords: helpwanted, perf
Target Milestone: mozilla0.9.1 → mozilla1.0
Changing platform
Hardware: All → Macintosh
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
don't move bugs that are in the 1.0 dependency tree. sorry.
Target Milestone: mozilla1.0.1 → mozilla1.0
1.2
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla1.2
What's the expected gain here?
Pretty small, probably. Maybe there are a few hotspots.
Target Milestone: mozilla1.2alpha → mozilla1.5alpha
Assignee: sfraser_bugs → bzbarsky
Status: ASSIGNED → NEW
I'm only looking at this for DOM nodes, really...  Those are where QI misses suck a lot (because of the XBL dependencies).
Assignee: bzbarsky → dougt
QA Contact: kandrot → xpcom
mass reassigning to nobody.
Assignee: dougt → nobody
From the table-driven QI bugs, IID misses are pretty common and take up the large majority of the time, and the table makes the loop really tight. I don't think we'll win more by microoptimizing this.
Status: NEW → RESOLVED
Closed: 15 years ago
Priority: P3 → P5
Resolution: --- → WONTFIX
Target Milestone: mozilla1.5alpha → Future
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: