Closed Bug 1658188 Opened 6 years ago Closed 5 years ago

Making a change to an IDL file causes a recompile of a lot of unrelated code, most notably in dom/

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: jorgk-bmo, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Yes, large portions of dom/, gfx/, layout/ and more get recompiled pushing compile times from a minute or so to 20 minutes. I guess that would severely impact backend developers. It's not only time consuming, it also pushes up the power bill and the wear of the machine. I'm just messing with some IDL files in bug 1563891, and I'm hit by large re-compile delays after every small change. Certainly not a way to attract volunteers.

Ditto. See bug 1571672 comment 61

Rob, any idea what might have changed?

Flags: needinfo?(rob)

Right away I see that by changing any IDL file whether it's one from comm-central or mozilla-central all of the .xpt files get regenerated. I'd guess that this is what triggers all that extra compilation based on Make being kind of dumb and basing it decision to build or not on file timestamps.

A Firefox build exhibits the same behavior. I tested this by making a change to toolkit/components/commandlines/nsICommandLine.idl and observed files in media/, layout/, etc being rebuilt.

I'd say that bug 1464542 which landed on 2020-07-10 is a prime suspect. I can try to test that theory later.

I don't have an answer but I think we can safely say that the changes in bug 1464542 started this. There's a new header file that gets generated: dist/include/xptdata.h and it looks like all of the c++ code that gets generated or rely on IDL files also depend on that header file. So updating an IDL file touches xptdata.h which causes the rebuild. I think.

Flags: needinfo?(rob)

Do you see a way to avoid rebuild for all idl changes?

Flags: needinfo?(kmaglione+bmo)
Regressed by: 1464542
Has Regression Range: --- → yes
Summary: Making a change to a comm-central IDL file causes a recompile of a lot of unrelated code, most notably in dom/ → Making a change to an IDL file causes a recompile of a lot of unrelated code, most notably in dom/
Component: Build Config → General
Product: Thunderbird → Firefox Build System

Only files that include nsIXPConnect.h or nsIVariant.h will generally need to be compiled. In principal it should be possible to avoid this when the output doesn't change (and the GENERATED_FILES system in moz.build tries to avoid it by only writing to files when they actually change), but it's not trivial to do with direct Makefile recipes. We also could move the interface names enum to a separate headers along with the lookup function, but I'd rather not, since it fundamentally belongs where it's declared now.

In any case, IDL files should be uncommon in practice, and ccache (which is the preferred configuration) tends to make it enough of a non-issue that I don't think it's worth the effort.

Flags: needinfo?(kmaglione+bmo)

This one is causing me quite a lot of pain right now - a lot of stuff I work on touches IDL files. So I'm really interested in any ways to mitigate things.
I think I'm probably looking at using multiple repo clones instead of branches to insulate different strands of work - separate builds, but overall lower rebuild time.

ccache shouldn't help much, should it? idl changes will still invalidate a load of dependent files and invalidate the cache, right?

I was running ccache for while, but generally found I had a really low cache hit rate in day-to-day work. Like way under 10%. So I ditched it. Perhaps I just had something screwed up?

Not expecting a miracle cure, but any ideas or tips most welcome!

Flags: needinfo?(kmaglione+bmo)

(In reply to Rob Lemley [:rjl] from comment #4)

Right away I see that by changing any IDL file whether it's one from comm-central or mozilla-central all of the .xpt files get regenerated. I'd guess that this is what triggers all that extra compilation based on Make being kind of dumb and basing it decision to build or not on file timestamps.

Just re-read this, and I guess ccache should help in this situation after all, assuming the regenerated files are the same as they were (and no timestamps in comments or anything like that!). As long as the hashes remain the same, it should all be fine...

Just to confirm - ccache does help a lot for this issue.
I've been using it today, and it's brought my annoying 30min recompile-if-any-idl-files-touched builds down to a couple of minutes. Yay!
Maybe not a miracle cure, but a miracle workaround, anyway :-)

Flags: needinfo?(kmaglione+bmo)

Ben, I wasn't familiar with how to enable ccache at all. After looking at the ccache man page and working with PATHs to clang stuff (which didn't work) I finally found this: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/ccache
Is this more or less what you did to enable ccache?

For me it defaults to 5G max size. Running build to see if that's enough. Also, I don't see problems with color display of compiler messages it seems.

(In reply to gene smith from comment #11)

Ben, I wasn't familiar with how to enable ccache at all. After looking at the ccache man page and working with PATHs to clang stuff (which didn't work) I finally found this: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/ccache
Is this more or less what you did to enable ccache?

Yes - that's the page I used as a guide!

I added the $ export CCACHE_COMPRESS="" line to my .bashrc and all the cached data seems to be gzipped nicely.
Doing a full release build from scratch today it poured about 1.1GB into the cache, so not too bad.
ccache defaulted to 5GB here too. I guess that's the new default. I'd upped mine to 10GB anyway before I started building, just in case.

I didn't even see the notes on compiler output colouring! The colouring appeared fine for me anyway, so I'd guess there are some settings somewhere that just cope with it by default now...

Note that sccache is recommended over ccache. I've updated the docs at https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/ccache accordingly.

The generated files only change when an interface is added or removed, which means it won't interfere with ccache, which relies on the checksums of the sources, not timestamps.

(In reply to Ricky Stewart from comment #13)

Note that sccache is recommended over ccache. I've updated the docs at https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/ccache accordingly.

Thanks, I was wondering what the sccache thing in ~/.mozbuild was about. I've switched over to sccache. I'm sure the info in comment 14 also applies to sccache as well as ccache.

Edit: I guess I've always ignored it but I see this message appear at the end of the build:
If you are building Firefox often, SCCache can save you a lot of time. You can learn more here: https://firefox-source-docs.mozilla.org/build/buildsystem/sccache-dist.html.
This link contains better info for possibly the windows or osx developer, but the link provided in comment 13 is more direct and to the point.
Also, just as a data point, a tb build with sccache first enabled took 65m. The next build after clobber took only 22m.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.