What did you use to collect the sampling data? Our project also experiences long build times (30 minutes on a 12 Core Xeon machine) using Qt5. I would like to be able to zero in on some of the issues instead of guessing at them.
-- Mike Jackson From: Interest <interest-boun...@qt-project.org> on behalf of Adam Light <acli...@gmail.com> Date: Monday, December 9, 2019 at 5:15 PM To: Qt Interest <Interest@qt-project.org> Subject: Re: [Interest] Tricks to improve moc performance? On Thu, Dec 5, 2019 at 5:09 PM Adam Light <acli...@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 _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
