Closed
Bug 149151
Opened 22 years ago
Closed 22 years ago
Use -lazyload to distribute cost of loading objects thruought their lifecycle
Categories
(SeaMonkey :: Build Config, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: nidheesh, Assigned: margaret.chan)
References
Details
(Keywords: fixedOEM, perf)
Attachments
(1 file)
704 bytes,
patch
|
netscape
:
review+
asa
:
approval+
|
Details | Diff | Splinter Review |
Monitoring process startup, I noticed libxpcom.so dlopen'ing
libdemangle.so.1 via it's .init section. Why can't this be a standard
dependency? or even better, couldn't this dlopen be deferred until
the demangling library is needed?
This is where I start talking about defferred loading. If you have to
load a lot of objects, is it possible to load them when you need them,
rather that all up front incase you need them?
After we've loaded the process and fired the initial .init's, ld.so.1
reveals a whole bunch of unreferenced dependencies (as ldd did above),
and more importantly some unused:
00496: 1: file=libjsj.so unused: does not satisfy any references.
00496: 1: file=libplc4.so unused: does not satisfy any refe
00496: 1: file=libgtk-1.2.so.0 unused: does not satisfy any refere
00496: 1: file=libgmodule-1.2.so.0 unused: does not satisfy any re
00496: 1: file=libXext.so.0 unused: cyclic group [3] member: unreferen
00496: 1: file=libX11.so.4 unused: cyclic group [3] member: unreferenc
00496: 1: file=libm.so.1 unused: does not satisfy any references
00496: 1: file=librt.so.1 unused: does not satisfy any references
00496: 1: file=libmp.so.2 unused: does not satisfy any references
00496: 1: file=libaio.so.1 unused: does not satisfy any references
00496: 1: file=libmd5.so.1 unused: does not satisfy any references
If you follow my advice in A, some of this might disappear. But an
additional technique is to use lazy-loading. Build your objects
with -zlazyload and then any dependencies will only be loaded when
a symbolic reference is made to them. This lazy-loading has the
effect of sharing the cost of loading objects throughout the
process lifecycle, rather than bearing all the costs up front.
Assignee | ||
Comment 1•22 years ago
|
||
Our linker expert suggests us to add these two options in the LDFLAGS. This is
for improving performance
Updated•22 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf
Summary: Use -lazyload to distribute cost of loading objects thruought their lifecycle → Use -lazyload to distribute cost of loading objects thruought their lifecycle
Assignee | ||
Comment 2•22 years ago
|
||
Hi seawood@netscape.com: Can you give me a r= for the above patch please? I
have put the flag in the place where it should only affect Solaris non-gcc
(i.e., using Sun's compiler) builds. Thanks, Margaret
Comment 3•22 years ago
|
||
Comment on attachment 89156 [details] [diff] [review]
Patch with -lazyload and -zcombreloc option for solaris
r=cls
Attachment #89156 -
Flags: review+
Assignee | ||
Comment 4•22 years ago
|
||
Thanks cls. Didn't get to come back to this until now. Who should I be asking
for sr= these days? Margaret
Comment 5•22 years ago
|
||
Per http://www.mozilla.org/hacking/reviewers.html, r=cls should be all you need
to check into the build system files. You can ask leaf for sr= if you really
feel the need for a second review. :)
Assignee | ||
Comment 6•22 years ago
|
||
Great. I am not going to bother leaf if I don't have to. I just think that the
process requires that. Glad to know that it doesn't. I'll check it in soon.
Thanks, Margaret
Assignee | ||
Comment 7•22 years ago
|
||
Tinderbox says that it is frozen for 1.1beta, I guess I'll wait till next week
for checkin then.
Comment 8•22 years ago
|
||
I did some test builds on Solaris 2.7/SPARC with Sun Workshop 7/FCS, the patch
seems to cause no problems.
----
Margaret Chan wrote:
> Tinderbox says that it is frozen for 1.1beta, I guess I'll wait till next week
> for checkin then.
It's now frozen for 1.1final... ;-(
But I do not see problems with these flags - what about sending an email to
drivers@mozilla.org and request approval for the "trunk" ?
Assignee | ||
Comment 9•22 years ago
|
||
Bummer... It seems to be frozen forever... Anyway, just send an email to
driver. I'll see what they say. Margaret
Comment 10•22 years ago
|
||
Margaret Chan wrote:
> Bummer... It seems to be frozen forever...
Yeah. Grrrrrrr... xx@@@!!!... ;-(
> Anyway, just send an email to driver.
Erm... do you mean you will send an email or should I send the request ?
Assignee | ||
Comment 11•22 years ago
|
||
Oops. Excuse my grammar.
> Anyway, just send an email to driver.
It should say "just sent an email to driver." since I have already done so. I
Am currently waiting for a reply from them. Margaret
Comment 12•22 years ago
|
||
Comment on attachment 89156 [details] [diff] [review]
Patch with -lazyload and -zcombreloc option for solaris
a=asa (on behalf of drivers) for checkin to 1.1
Attachment #89156 -
Flags: approval+
Comment 13•22 years ago
|
||
Margaret Chan:
Please read http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey :
-- snip --
"OPEN means that the tree is open only to drivers-approved checkins that have
been approved within the three days prior to the checkin."
-- snip --
or short: Driver approval is only valid if you check the code "in" ASAP; the
approval expires after three days...
... can you check the patch "in" before the a=asa (see comment #12) expires,
please ?
Assignee | ||
Comment 14•22 years ago
|
||
Thanks for the reminder, Roland. I just did. Marked it resolved fixed.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•22 years ago
|
Whiteboard: branchOEM+ → branchOEM+ fixedOEM
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•