717620 - Use PARALLEL_DIRS in GFX

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[Benoit Girard (:BenWa)]

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.

Comment 1

[Benoit Girard (:BenWa)]

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.

Comment 2

[Benoit Girard (:BenWa)]

Attachment: patch

This passes try. What do you think Ted?

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

Will parallel 'please' make this happen sooner?

please
plllllllllllease
pleeaaaaaase
plizzzzzzzzzzz
pretty please

Comment 4

[Joe Drew (not getting mail)]

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

Comment 5

[Mozilla RelEng Bot]

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/[e-mail]-a4b7040b9bf2

Comment 6

[Benoit Girard (:BenWa)]

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

[(not currently active) Ted Mielczarek]

(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

[(not currently active) Ted Mielczarek]

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!

Comment 9

[Benoit Girard (:BenWa)]

I didn't see a speed improvement so I'm not interested in landing this.