Closed
Bug 717620
Opened 13 years ago
Closed 13 years ago
Use PARALLEL_DIRS in GFX
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: BenWa, Assigned: BenWa)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
patch
|
ted
:
review+
|
Details | Diff | Splinter Review |
Best description so far I've found of things to avoid: https://bugzilla.mozilla.org/show_bug.cgi?id=462381#c0 I don't want to waste my CPU on this so I'm just pushing this to try and hoping for the best.
Assignee | ||
Updated•13 years ago
|
Blocks: build-perf
Assignee | ||
Comment 1•13 years ago
|
||
Ted, is there any reason why we're not doing this in GFX or lack of devs to work on it? I'm curious to try it anyways.
Assignee | ||
Comment 2•13 years ago
|
||
This passes try. What do you think Ted?
Assignee: nobody → bgirard
Status: NEW → ASSIGNED
Attachment #588129 -
Flags: review?(ted.mielczarek)
Comment 3•13 years ago
|
||
Will parallel 'please' make this happen sooner? please plllllllllllease pleeaaaaaase plizzzzzzzzzzz pretty please
Comment 4•13 years ago
|
||
Things in other directories in gfx/ _definitely_ depend on the headers in 2d/. Will that be an issue?
Comment 5•13 years ago
|
||
Try run for a4b7040b9bf2 is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=a4b7040b9bf2 Results (out of 172 total builds): success: 150 warnings: 17 failure: 5 Builds (or logs if builds failed) available at: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/b56girard@gmail.com-a4b7040b9bf2
Assignee | ||
Comment 6•13 years ago
|
||
I benchmark this by deleting objdir/gfx and timing the builds without the patch. I go from 1m41s to 1m37s. Not really worth while :(
Comment 7•13 years ago
|
||
(In reply to Benoit Girard (:BenWa) from comment #1) > Ted, is there any reason why we're not doing this in GFX or lack of devs to > work on it? I'm curious to try it anyways. It's strictly lack of resources. I implemented it in content, and Mitch implemented it in layout, which are two of our largest parts of the codebase. There were some decent wins there just because of the sheer number of directories and source files. It's been a while since I touched this, but my comment from the other bug sounds right (and past-Ted probably knows better than present-Ted anyway). Essentially, when processing a Makefile, we run "make export on all PARALLEL_DIRS at the same time", then "make export on all DIRS serially", then "make libs on PARALLEL_DIRS in parallel" then "make libs on DIRS serially". There's a potential alternate tack to take here, which is to do like bug 595513 (and subsequent bugs) have done and simply push data from sub-DIRS Makefiles up into the parent dir Makefile. If you have gfx/{a,b,c}, you may be able to simply do like: CPPSRCS = a/a.cpp b/b.cpp c/c.cpp etc. in gfx/Makefile.in and remove {a,b,c}/Makefile.in. The only downside to that approach is that you can't make directly in the subdirectories anymore. (But making in the top-level gfx dir shouldn't be any slower, so it might not matter.)
Comment 8•13 years ago
|
||
Comment on attachment 588129 [details] [diff] [review] patch Review of attachment 588129 [details] [diff] [review]: ----------------------------------------------------------------- As long as this doesn't break anything, it's fine with me!
Attachment #588129 -
Flags: review?(ted.mielczarek) → review+
Assignee | ||
Comment 9•13 years ago
|
||
I didn't see a speed improvement so I'm not interested in landing this.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•