Closed Bug 271845 Opened 20 years ago Closed 17 years ago

do_GetInterface causes unnecessary bloat

Categories

(Core :: XPCOM, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: bernard.alleysson, Unassigned)

Details

Attachments

(2 files, 2 obsolete files)

Use nsGetInterfaceWithError/nsGetInterface to avoid extra member mErrorPtr when
it is not needed
Attached patch patch 1 (obsolete) — Splinter Review
nsGetInterface/nsGetInterfaceWithError, make nsGetInterface* operator() not
virtual, and remove overhead of nsCOMPtr<> from nsGetInterface* operator()
Comment on attachment 167107 [details] [diff] [review]
patch 1

Brian, would you review the patch ?
It's the same as bug 264456
(nsGetServiceBy*WithError)
Attachment #167107 - Flags: review?(bryner)
Comment on attachment 167107 [details] [diff] [review]
patch 1

looks ok, i'd like to see some codesize numbers first though
Attachment #167107 - Flags: review?(bryner) → review+
I've just compiled Mozilla Suite on Windows with VC7 and there's no codesize
change. A quick examination shows that gklayout.dll is 1Kb smaller while
xpcom_core.dll is 1Kb bigger but overall the size of all DLLs is 12830208 with
or without the patch.

VC generates better code than GCC and there could be a small codesize win on Linux.

This patch is a small perf win because it makes operator() not virtual, it
removes nsCOMPtr<> usage from operator() and because the generated code is
slightly better at all call sites for do_GetInterface(ptr) variant.
I think that callers expect do_GetInterface to be as "fast" as possible and this
patch can help.

This patch also allows nsGetInterface operator() to be removed and inlined at
its call sites (only 2 call sites, in nsCOMPtr.h, nsCOMPtr.cpp !) so there's
more to come ...
Attached patch patch 2 (obsolete) — Splinter Review
It should be a small code size win on Linux.
Same as the previous patch but changed "if ( factoryPtr )" to "if
NS_SUCCEEDED(status)" in nsIInterfaceRequestorUtils.cpp, for correctness.
Attachment #167107 - Attachment is obsolete: true
Attachment #168750 - Flags: superreview?(darin)
Attachment #168750 - Flags: review?(bryner)
Comment on attachment 168750 [details] [diff] [review]
patch 2

can you post codesize reduction numbers?  i'd like to know how this impacts the
size of mozilla as well as the size of the xpcom_core library.
Attached patch patch 3Splinter Review
Same as the previous patch, but inlined/removed nsGetInterface operator(), for
more performance, (nsIInterfaceRequestorUtils.cpp should be removed)
Attachment #168750 - Attachment is obsolete: true
Attachment #168959 - Flags: superreview?(darin)
Attachment #168959 - Flags: review?(bryner)
Attachment #168750 - Flags: superreview?(darin)
Attachment #168750 - Flags: review?(bryner)
On Windows, the total saving is 2 kb and you have a more efficient
do_GetInterface() implementation (no more virtual call, no more nsCOMPtr<>
overhead, and inlined code).

I can't have code size numbers on Linux, sorry, all I can say is that it is
similar to what was done with nsQueryInterface. There are about 400
do_GetInterface(), most of them don't use the error variant. Looking at numbers
for nsQueryInterface, I think that it should save about 5Kb. And of course
you'll still get a faster do_GetInterface().
Comment on attachment 168959 [details] [diff] [review]
patch 3

My personal thought is that the numbers don't justify adding this complexity to
the code.  Darin, what do you think?
Attachment #168959 - Flags: review?(bryner) → review-
Comment on attachment 168959 [details] [diff] [review]
patch 3

doesn't seem worth it to me either.  sorry, i know this was a large patch, and you are probably unhappy to see it get rejected like this.  next time, i recommend doing more proof-of-concept work up front.
Attachment #168959 - Flags: superreview?(darin) → superreview-
QA Contact: xpcom
(In reply to comment #10)
> (From update of attachment 168959 [details] [diff] [review] [edit])
> doesn't seem worth it to me either.  sorry, i know this was a large patch, and
> you are probably unhappy to see it get rejected like this.  next time, i
> recommend doing more proof-of-concept work up front.

Does that make this bug WONTFIX?
Assignee: dougt → nobody
Marking WONTFIX per comments #9 and #10. Bernard, feel free to reopen if you object.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: