[Development] QMetaMethod in Qt 6
aclight at gmail.com
Thu May 28 19:19:58 CEST 2020
On Thu, May 28, 2020 at 9:55 AM Oswald Buddenhagen <
oswald.buddenhagen at gmx.de> wrote:
> On Thu, May 28, 2020 at 08:43:14AM -0700, Adam Light wrote:
> >> [include mocs]
> >Changing Qt in a way that would require #including the moc output from
> >the .cpp file might cause noticeable increase in build times unless moc
> >is also changed.
> care to explain how _exactly_ that would be the case? your report
> demonstrates an issue with _generating_ the moc files, not compiling
I'm including generating moc files in "build time". I'm not saying that
compiling the .cpp files will take significantly longer, but if a .cpp file
has a #include "myclass.moc" type statement, that .cpp file has to be
processed by moc, which will require moc to satisfy all other #includes in
that .cpp file, which could be significantly slower than if moc processed
the class declaration in the .h file, since .h files typically forward
declare to the extent possible to minimize the number of included files.
As I pointed out in the issue, mocing all files in our application takes
about 1/3 of the time of the entire build under the *best* circumstances
(see first table in the Possible Solutions, bindflt OFF column). Under
non-optimal circumstances (which can be tricky to avoid), mocing all files
takes roughly 2.5 times the *rest of the build* combined (same table,
compare bindflt OFF versus bindflt ON in Default moc row, also demonstrated
in the last table in the Additional complication section, which shows
Creator build times). Note that when comparing bindflt ON vs. bindflt OFF
times in any of those tables, almost 100% of the difference between ON and
OFF is spent in moc.exe.
As I explained in Note 1 of the bug report, the VS compiler uses different
system API calls to satisfy #includes than moc does, so the compiler itself
isn't a bottleneck.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development