[Interest] Tricks to improve moc performance?

[Adam Light]

On Thu, Dec 5, 2019 at 5:09 PM Adam Light <aclight at gmail.com> wrote:

>
> Does anyone else have any ideas of how we could change our build to
> improve moc performance when Windows decides to be "slow"? Like, for
> example, is there any way to have the moc calls run with only a few moc
> processes running at once but have the rest of the build done with all
> threads running. I'm pretty sure that the OS slowdown has something to do
> with thread contention of some sort.
>
>
The problem with moc.exe is even worse than I first realized.

Even when Windows is in the "fast" state (that is, a full rebuild takes 4-5
minutes instead of 16-18 minutes), the vast majority of the build time is
spent in moc.exe.

I just collected sampling data for an entire build, excluding the qmake
step. So this is the entirety of jom.exe and everything it calls during the
build. Windows 10, debug build of our application, VS2017. I'm not using
any /j flag with jom, so it will use all available threads (16 core/32
threads).

The build took 4:54. During that time, there were a total of 551 moc.exe
processes that ran, and those processes took a total of 3,896 seconds of
CPU time. There were also 1270 cl.exe processes which took a total of 965
seconds of CPU time. Everything else (link.exe, ui.exe, jom.exe, was
minimal) compared to these two. So moc.exe was running almost 4 times as
long as cl.exe. That seems crazy to me.

When I previously analyzed the sampling data during a moc.exe run, it was
clear that the vast majority of the time was spent satisfying the includes,
and most of that was checking whether a concatenation of an include path
and a file name are a valid file (eg. include/path1/stdio,
include/path2/stdio, etc.). It seems like the compiler (cl.exe) would need
to do essentially the same thing when compiling each individual file, but
it's not nearly as slow as moc.

Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20191209/3cac63fd/attachment.html>