If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Use PARALLEL_DIRS in GFX

RESOLVED WONTFIX

Status

()

Core
Graphics
RESOLVED WONTFIX
6 years ago
6 years ago

People

(Reporter: BenWa, Assigned: BenWa)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

6 years ago
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

6 years ago
Blocks: 459891
(Assignee)

Comment 1

6 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

6 years ago
Created attachment 588129 [details] [diff] [review]
patch

This passes try. What do you think Ted?
Assignee: nobody → bgirard
Status: NEW → ASSIGNED
Attachment #588129 - Flags: review?(ted.mielczarek)
Will parallel 'please' make this happen sooner?

please
plllllllllllease
pleeaaaaaase
plizzzzzzzzzzz
pretty please
Things in other directories in gfx/ _definitely_ depend on the headers in 2d/. Will that be an issue?

Comment 5

6 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

6 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 :(
(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 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

6 years ago
I didn't see a speed improvement so I'm not interested in landing this.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.