[Development] Qt Compilation Speed

[Lars Knoll]

On 3 Jan 2022, at 14:21, Thiago Macieira <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> wrote:

On Monday, 3 January 2022 05:43:53 -03 Marc Mutz wrote:
Hi,

The Qt Creator folks have noted that compilation of Qt projects against Qt
6.2 is sometimes almost twice as slow as it was in 5.15:
https://bugreports.qt.io/browse/QTBUG-97601

While we have some ideas where this may come from (including more std
headers, qmetatype compile-time typename construction, qglobal.h becoming
larger and larger), most of these should be fixed by PCH, yet PCH builds
are also slower.

Compile times to matter, as they directly impact the productivity of all of us and of our users. So if we can find ways to reduce them, that’s probably a worthwhile effort.

The change to C++17 makes a huge difference too, regardless of PCH. That
#include <algorithm> in qglobal.h adds up to 300 ms in each build without PCH,
and a considerable amount with it too. And it gets worse with C++20 and
ranges.

I don't know what Qt Creator used as C++ standard before 6.x, so this might be
stale information.

We can't fix this, if it s the issue. The C++ standard is cramming more stuff
in <algorithm>, not new headers, so it's not a QoI either.

This sucks, but I also don’t see an easy way to avoid most of those headers. I’ve played around a bit to see what we could gain by forward declaring (yes, I know it’s UB according to the C++ standard…) std types, but didn’t really get very far, but I also only spent an hour or two on it.

qglobal.h does however have quite a few legacy includes at the end that should not really be there. Some of those include quite a set of std headers. I wonder whether removing those and explicitly adding them where required would help.

I also wonder if we can avoid <algorithm>. It’s only used in very few public headers in QtCore, and we might be able to move those usages into the implementation.

One other possible solution to improve compile times is the hack we used 15 years ago in KDE, where we grouped many .cpp files into one compilation unit. There’s however a balance needed here, as it reduces the efficiency of -j, but maybe compiling 4-8 .cpp files as one unit could help.

Cheers,
Lars


The questions that we face now are a) do we care and b) if we do, then what
metrics should we use to define success?

Clang has a mode to tell you how much time it's spending on each phase. If the
issue is headers, we can find unnecessary ones and remove them easily, with an
automated too.

Splitting headers to make for shorter builds I'd say we can only do for a few
headers. Find the biggest offenders in corelib and try to see what we can do.
Some minor source compat breakage due to indirect inclusions getting removed
is acceptable. But it's not something that can easily be done for a great deal
many more headers: it would likely be more effort than it's worth the outcome.

And remove #include <algorithm> in qglobal.h, if we can. Maybe add a #define
that skips including it and possibly disables some other functionality that
you'd have to #include yourself. QGLOBAL_LEAN_AND_MEAN?

--
Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com/>
 Software Architect - Intel DPG Cloud Engineering



_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20220103/5fc5def4/attachment-0001.htm>