Closed
Bug 518107
Opened 15 years ago
Closed 15 years ago
don't force re-linking on every build pass for PGO builds
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.9.3a1
People
(Reporter: ted, Assigned: ted)
References
(Blocks 1 open bug, )
Details
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Callek
:
review+
|
Details | Diff | Splinter Review |
Currently we force re-linking for every exe and dll in the tree in both phases of a PGO build on Windows. My original assumption here was that we needed this, since if you've re-linked in phase 1, you must re-link in phase 2. This is a sloppy solution though, since we wind up re-linking libxul twice for every PGO build, even if there were no changes touching it. This takes forever. A smarter way to do this would be to touch a file if we link in phase 1, and then make the binary depend on that file in phase 2, so it gets re-linked only if phase 1 linked. This way if normal dependencies cause a re-link, then we re-link twice, but if they don't, then we skip that entirely. This should save a ton of time on tinderbox builds.
Assignee | ||
Updated•15 years ago
|
Blocks: build-perf
Assignee | ||
Comment 1•15 years ago
|
||
PGO with Visual C++ 2005 building on Windows 7 seems to be broken. The linker crashes every time while linking libxul. I'm going to install VC2k8 and give it a shot.
Assignee | ||
Comment 2•15 years ago
|
||
I'm having no better luck with VC9, it crashes in the same way. I filed a Visual Studio bug with Microsoft, we'll see if anything useful comes out of that. I guess switching to Windows 7 wasn't the best idea! Anyway, this patch seems reasonable, I'm just not able to test it properly. This should cause us to only relink in the second phase when we've linked in the first phase.
Assignee | ||
Comment 3•15 years ago
|
||
This looks good from my limited testing in js/src. It builds properly, and dep builds without any changes don't do anything, but touching a source file and rebuilding causes all the right re-links to happen. I have an objdir where I've already done a full build, then: touch js/src/jsapi.cpp; time (make -C ../obj-firefox-pgo/js/src/ MOZ_PROFILE_GENERATE=1 && make -C ../obj-firefox-pgo/js/src/ MOZ_PROFILE_USE=1) real 4m22.111s time (make -C ../obj-firefox-pgo/js/src/ MOZ_PROFILE_GENERATE=1 && make -C ../obj-firefox-pgo/js/src/ MOZ_PROFILE_USE=1) real 0m2.496s Much faster dep build. :) (and that's just JS!)
Attachment #402324 -
Attachment is obsolete: true
Attachment #402367 -
Flags: review?(benjamin)
Updated•15 years ago
|
Attachment #402367 -
Flags: review?(benjamin) → review+
Assignee | ||
Comment 4•15 years ago
|
||
Pushed to m-c: http://hg.mozilla.org/mozilla-central/rev/11de05178d08 We should probably take this on branches, too, since it ought to decrease build times in many cases, and lower our overall infra load.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Assignee | ||
Comment 5•15 years ago
|
||
This has apparently caused some recent bustage: http://tinderbox.mozilla.org/showlog.cgi?tree=Firefox&errorparser=unix&logfile=1254194359.1254199979.23433.gz&buildtime=1254194359&buildname=WINNT%205.2%20mozilla-central%20build&fulltext= I guess those slaves just need a clobber.
Updated•15 years ago
|
Flags: in-testsuite-
Updated•15 years ago
|
Attachment #429346 -
Flags: review?(bugspam.Callek) → review+
Comment 7•15 years ago
|
||
Comment on attachment 429346 [details] [diff] [review] (Bv1-CC) Copy it to comm-central (1.9.2+) [Checkin: Comment 7] http://hg.mozilla.org/comm-central/rev/dfcb8184538f
Attachment #429346 -
Attachment description: (Bv1-CC) Copy it to comm-central (1.9.2+) → (Bv1-CC) Copy it to comm-central (1.9.2+)
[Checkin: Comment 7]
Updated•15 years ago
|
Blocks: C192ConfSync
Updated•7 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•