Re: [Interest] Tricks to improve moc performance?
On Friday, 6 December 2019 15:10:41 PST Adam Light wrote: > > Yes: https://github.com/qt/qtbase/blob/dev/util/includemocs/includemocs.pl > > Thanks. That saved a lot of time. > > For what it's worth, after changing all of our code to directly #include > the moc output, the total build time dropped by around 10%. That's helpful. Nice. Did you notice a size improvement in your optimised binaries too? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
On Friday, 6 December 2019 10:06:24 PST Richard Weickelt wrote: > > This solution gets you a single build for all the the mocs, which is good, > > but won't generate the best code that Peppe was talking about. You want > > the moc for a given class to be in the class's own .cpp. > > Unless you build with link-time optimization enabled, I suppose. Because > then translation units are no longer an optimization boundary. I don't know if it triggers this warning in LTO mode. I usually consider them complementary options, so best to use both. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
On Friday, 6 December 2019 10:21:24 PST Michael Jackson wrote: > Dear Thiago, > Could you expand a bit on your comment? We use CMake for our build > system and the AUOT_MOC feature. I just would like to know what exactly I > am missing by doing this. Run the includemocs script that I linked to: make every .cpp of a class that has a Q_OBJECT in aheder #include the moc_*.cpp file that moc generates. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
On Fri, Dec 6, 2019 at 9:57 AM Thiago Macieira wrote: > On Friday, 6 December 2019 06:30:36 PST Adam Light wrote: > > Yes, that's definitely on my TODO list, though I don't think it's going > to > > do much to address the current situation in which moc itself is the main > > bottleneck. But any improvement will help. > > > > Does anyone know of a script or other automated way to add these > includes? > > Yes: https://github.com/qt/qtbase/blob/dev/util/includemocs/includemocs.pl > > Thanks. That saved a lot of time. For what it's worth, after changing all of our code to directly #include the moc output, the total build time dropped by around 10%. That's helpful. Adam ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] fatal error: 'type_traits' file not found - Qt 5.14 Preview Android
Hi, I’m giving a try to Qt 5.14 Preview on Android and when compiling an existing project I’m having this: In file included from /Users/nsantos/Qt/5.14.0/android/include/QtGui/QGuiApplication:1: In file included from /Users/nsantos/Qt/5.14.0/android/include/QtGui/qguiapplication.h:43: In file included from /Users/nsantos/Qt/5.14.0/android/include/QtGui/qtguiglobal.h:43: /Users/nsantos/Qt/5.14.0/android/include/QtCore/qglobal.h:45:12: fatal error: 'type_traits' file not found Does anyone knows how to solve this? I’ve been googling around but couldn’t find a solution yet Thanks! Regards, Nuno___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Klocwork errors in Qt
On 12/4/2019 9:31 AM, Roland Hughes wrote: If you think auto won't be removed as a failed experiment, how about "new"? Deprecated in C++20 and slated for removal in C++23. https://www.modernescpp.com/index.php/no-new-new Some more reading on the removal of pointers https://www.fluentcpp.com/2018/04/01/cpp-will-no-longer-have-pointers/ TL;DR: This was a 2018 April Fool's joke. Cheers, -Max "no auto" Paperno ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
On 12/6/19, 12:52 PM, "Interest on behalf of Thiago Macieira" wrote: On Friday, 6 December 2019 01:16:31 PST Kevin Funk via Interest wrote: > On that note, CMake goes one step further and removes the need to do this > manually. Using CMake's AUTOMOC feature, CMake will automatically create ONE > mocs_compilations.cpp file per target which in turn includes all generated > "moc_XYZ.cpp" files. > > Quoting: > > "Header files that are not included by an #include "moc_.cpp" > statement are nonetheless scanned for Q_OBJECT or Q_GADGET macros. The > resulting moc_.cpp files are generated in custom directories and > automatically included in a generated > /mocs_compilation.cpp file, which is compiled as part of > the target." That's good, but not ideal. This solution gets you a single build for all the the mocs, which is good, but won't generate the best code that Peppe was talking about. You want the moc for a given class to be in the class's own .cpp. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products Dear Thiago, Could you expand a bit on your comment? We use CMake for our build system and the AUOT_MOC feature. I just would like to know what exactly I am missing by doing this. -- Mike Jackson ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
> This solution gets you a single build for all the the mocs, which is good, > but > won't generate the best code that Peppe was talking about. You want the moc > for a given class to be in the class's own .cpp. Unless you build with link-time optimization enabled, I suppose. Because then translation units are no longer an optimization boundary. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
> By the way: does anyone know about an implementation that avoids moc runs in > a similar way how ccache avoids compile runs ? You mean concatenating header and source files containing a Q_OBJECT macro and feeding moc the result? I cannot imagine that this would be a safe transformation in general. Moc accepts defines and include paths on command line so I would suppose that it tries very hard to parse the C++ code, to expand macros and to resolve includes. It might work for limited use-cases though. I'd say concatenating the output of moc and compiling that in one go is the only safe shortcut in this process. Richard ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
On Friday, 6 December 2019 06:30:36 PST Adam Light wrote: > Yes, that's definitely on my TODO list, though I don't think it's going to > do much to address the current situation in which moc itself is the main > bottleneck. But any improvement will help. > > Does anyone know of a script or other automated way to add these includes? Yes: https://github.com/qt/qtbase/blob/dev/util/includemocs/includemocs.pl -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
On Friday, 6 December 2019 01:52:52 PST Giuseppe D'Angelo via Interest wrote: > Sorry, not the code generated by moc -- the code generated by the > > compiler/linker. See e.g. here: > > https://codereview.qt-project.org/c/qt/qtbase/+/152423 it also enables the "private member never used' warning in Clang: if it can see the definition of all functions in a class, it can tell whether none of them accessed a given member. If your moc's output in a separate translation unit, then neither had all member functions. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
On Friday, 6 December 2019 01:16:31 PST Kevin Funk via Interest wrote: > On that note, CMake goes one step further and removes the need to do this > manually. Using CMake's AUTOMOC feature, CMake will automatically create ONE > mocs_compilations.cpp file per target which in turn includes all generated > "moc_XYZ.cpp" files. > > Quoting: > > "Header files that are not included by an #include "moc_.cpp" > statement are nonetheless scanned for Q_OBJECT or Q_GADGET macros. The > resulting moc_.cpp files are generated in custom directories and > automatically included in a generated > /mocs_compilation.cpp file, which is compiled as part of > the target." That's good, but not ideal. This solution gets you a single build for all the the mocs, which is good, but won't generate the best code that Peppe was talking about. You want the moc for a given class to be in the class's own .cpp. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
On Friday, 6 December 2019 00:42:22 PST Uwe Rathmann wrote: > A side note: the code of Qwt project runs with all Qt versions >= 4.4 > and therefore allows to compare the impact of the Qt headers on the > compile time. It is some time ago, when I did this, but the differences > were significant. IIRC there was a major slowdown around ~4.7 that gets > worse during the Qt5 cycle. The biggest slowdown of Qt 5.0 was the removal of QT_NO_STL. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Best way to threaded render (images) going forward?
I solved this problem, thanks all. So our previous video surface WAS QPainter on a separate thread already, it is possible. It was also cross platform. But, it was the deprecated QGLWidget. It turns out even if I could have gotten this all working in QOpenGLWidget, that newer widget had a bug so we can't use it. https://bugreports.qt.io/browse/QTBUG-49657 Our app does run in full screen and that bug still exists in 5.13.x So, I went to a new, simpler model and it's working. I subclassed the regular QWidget for the surface, and made a worker thread that uses a QPainter on a QImage. I do all the resizing of the frames, compositing them together, etc in that thread, then just pass the final QImage via signal to the QWidget to draw in the UI thread. It's working fine, on all platforms again, at 60fps with no apparent impact on the rest of the UI. If it helps anyone, here is the final thread with some example code: https://forum.qt.io/topic/109480/proper-way-to-pass-qimage-from-thread-through-signal/2 So in the final though, in Renderer::render(), I'm actually doing all the work stated above, not just drawImage. On Fri, Dec 6, 2019 at 8:56 AM Uwe Rathmann wrote: > On 11/22/19 2:14 PM, Roland Hughes wrote: > > > There have been many requests over the years to allow QPainter > > operations outside of the primary thread. In particular for running > > graphs like heart rate monitors which are just a brick on the screen the > > user generally cannot interact with. > > With X11 it is at least possible to draw outside of the paint event - > see Qt::WA_PaintOutsidePaintEvent. This type of operation is used in the > Qwt plot package for exactly the use case you have mentioned. > > I'm not 100% sure if it wouldn't be possible to the same in an extra > thread. > > With Qt3 it was even possible to draw in XOR mode, what was at that time > the way how rubberbands were implemented. This was an operation where > you could erase content without having to repaint from scratch. But this > one seems to be gone forever. > > Uwe > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > -- Wes Krasko www.worldwidewes.com www.kraskofamily.com "Stay away from negative people. They have a problem for every solution." ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Best way to threaded render (images) going forward?
On 11/22/19 2:14 PM, Roland Hughes wrote: There have been many requests over the years to allow QPainter operations outside of the primary thread. In particular for running graphs like heart rate monitors which are just a brick on the screen the user generally cannot interact with. With X11 it is at least possible to draw outside of the paint event - see Qt::WA_PaintOutsidePaintEvent. This type of operation is used in the Qwt plot package for exactly the use case you have mentioned. I'm not 100% sure if it wouldn't be possible to the same in an extra thread. With Qt3 it was even possible to draw in XOR mode, what was at that time the way how rubberbands were implemented. This was an operation where you could erase content without having to repaint from scratch. But this one seems to be gone forever. Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Klocwork errors in Qt
On 12/4/19 5:00 AM, Thiago Macieira wrote: On Tuesday, 3 December 2019 17:36:37 PST Christian Gagneraud wrote: My point is that this sort of bugs are really hard to detect during code review. This is subtle & nasty 'feature' of QStringBuilder (a choice in its implementation). Understood, but it shows up quickly when running the code or, at worst, Valgrind or ASan time. It hasn't affected us in Qt itself because we use the Almost Never Auto coding style. That style is also required in any shop using actual software engineering, particularly in the medical device world. Auto should have never been added to the language. It was an attempt to "dumb down" the skill level, thus lowering the bar for new developers. A shortcut is the longest distance between any two points, you just may not realize it at the time you take it. It won't be that much longer before auto ends up on the trash heap with digraphs and trigraphs. https://en.wikipedia.org/wiki/Digraphs_and_trigraphs IBM at least had a legitimate reason for fighting that fight. EBCDIC didn't have the characters and neither did the keyboards. https://www.oreilly.com/library/view/signalr-real-time-application/9781782164241/graphics/4241OS_01_01.jpg If you think auto won't be removed as a failed experiment, how about "new"? Deprecated in C++20 and slated for removal in C++23. https://www.modernescpp.com/index.php/no-new-new std::auto_ptr was deprecated in C++11 and removed in C++17. Smart pointers have had more than their fair share of growing pains. Had to be ripped out of the last project I was on. They just weren't as smart as the name implies. Most likely they will go away with "new." https://www.fluentcpp.com/2018/04/01/cpp-will-no-longer-have-pointers/ The chasm between C and C++ will then be more than an ocean wide. C++ and by extension Qt, won't be usable when you have hardware which must be addressed via addresses and memory mapping, or so it would seem. Some more reading on the removal of pointers https://www.fluentcpp.com/2018/04/01/cpp-will-no-longer-have-pointers/ Removal of new and pointers is really going to hose .UI files and however many thousand examples like this https://riptutorial.com/qt/example/20811/setting-a-ui-widget-s-stylesheet are floating around. Not to mention QWidget *parent parameters used everywhere like the Analog Clock Example. https://doc.qt.io/qt-5/qtwidgets-widgets-analogclock-example.html QML and basically any other scripting/interpreted language is unusable where human life is potentially at risk, i.e. Medical devices, crane control systems. I'm sure others can list more. -- Roland Hughes, President Logikal Solutions (630)-205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Best way to threaded render (images) going forward?
On 11/22/19 5:00 AM, Wesley Krasko wrote: Thanks. For now anyways I'm trying to just move from QGLWidget to QOpenGLWidget, buy time. Can I get some help? In the QGLWidget one I currently have there is a separate thread to render and it uses QPainter. I'm trying to do the same for the new class but I can't seem to get a QPainter working no matter what! The app runs but as soon as drawing starts it crashes because, but I"m using similar methods to what I did before. If I comment out just the attempt to create QPainter, it works fine, renders fast just doing the glclear part. Hopefully I can attach here. There is a lot of "Extra" from our previous surface/class, but it's not yet used anyways. As mentioned, this is working as is, but where you find "//TODO HERE" in the code, I tried many ways to use a QPainter in the thread without success. Honestly, I'm shocked you ever got it to work. The original Achilles' Heel of Qt was the fact the GUI thread had to be the primary thread and all GUI (QPainter) operations had to occur there. Over the years they've added some non-rendered data classes for loading of images which could be threaded off, but they had to be moved into an object in the GUI thread to be rendered. There have been many requests over the years to allow QPainter operations outside of the primary thread. In particular for running graphs like heart rate monitors which are just a brick on the screen the user generally cannot interact with. https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Ftse1.mm.bing.net%2Fth%3Fid%3DOIP.N-43HpXNXBnwYyOgweb19wHaEL%26pid%3DApi=1 -- Roland Hughes, President Logikal Solutions (630)-205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
On Fri, Dec 6, 2019 at 12:42 AM Uwe Rathmann wrote: > On 12/6/19 2:09 AM, Adam Light wrote: > > > Does anyone else have any ideas of how we could change our build to > > improve moc performance when Windows decides to be "slow"? > > Something you can try is to include the moc file at the end of your cpp > file. This can be done like this: > > #include "moc_XYZ.cpp" > > Yes, that's definitely on my TODO list, though I don't think it's going to do much to address the current situation in which moc itself is the main bottleneck. But any improvement will help. Does anyone know of a script or other automated way to add these includes? Adam ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
On 12/6/19 9:48 AM, Giuseppe D'Angelo via Interest wrote: This trick is used in several places in Qt itself (look for "includemoc" in commits). Not only it helps build times but also it produces slightly better code overall. By the way: does anyone know about an implementation that avoids moc runs in a similar way how ccache avoids compile runs ? Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] cpputest with QTest output issue on embedded target console
On Fri, 6 Dec 2019 08:23:20 +0530 Ramakanth Kesireddy wrote: > When unit test binary(using cpputest to run the testcases + QTest for the > specific Qt functionality)is executed on embedded target(linux), it doesnot > shows any test summary/results with respect to number of testcases run on > console. > > There is no issue when it is run on Ubuntu linux. > > Whether Qt redirects the standard output or any environment variable to see > the output on console or any other reason? The output might go to some syslog. Try setting QT_LOGGING_TO_CONSOLE=1. Christian ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
Hi, Il 06/12/19 10:48, Dmitriy Purgin ha scritto: Hi Giuseppe, > This trick is used in several places in Qt itself (look for "includemoc" > in commits). Not only it helps build times but also it produces slightly > better code overall. Could you please elaborate what exactly do you mean under 'better code'? How does including the xxx_moc.cpp affect the code generation by moc? If moc decides to generate a better code when included explicitly in a cpp file, why can't it generate the same better code otherwise? Is there a technical reason for it? Sorry, not the code generated by moc -- the code generated by the compiler/linker. See e.g. here: https://codereview.qt-project.org/c/qt/qtbase/+/152423 HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
Hi Giuseppe, > This trick is used in several places in Qt itself (look for "includemoc" > in commits). Not only it helps build times but also it produces slightly > better code overall. Could you please elaborate what exactly do you mean under 'better code'? How does including the xxx_moc.cpp affect the code generation by moc? If moc decides to generate a better code when included explicitly in a cpp file, why can't it generate the same better code otherwise? Is there a technical reason for it? Thanks! Cheers Dmitriy On Fri, Dec 6, 2019 at 9:49 AM Giuseppe D'Angelo via Interest < interest@qt-project.org> wrote: > Il 06/12/19 09:42, Uwe Rathmann ha scritto: > > Something you can try is to include the moc file at the end of your cpp > > file. This can be done like this: > > > > #include "moc_XYZ.cpp" > > > > This type of construction is at least supported by qmake. > > > > This does not reduce the number of moc runs, but it reduces the number > > of compiler runs. As a rule of thumb for not too large classes I would > > expect, that ~50% of the compile time is spent inside the Qt headers and > > by including the moc file the overall compile time goes down by 33% as > > the headers need to be processed only once. > > This trick is used in several places in Qt itself (look for "includemoc" > in commits). Not only it helps build times but also it produces slightly > better code overall. > > HTH, > -- > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > ___ > 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
Re: [Interest] Tricks to improve moc performance?
On Friday, 6 December 2019 09:48:51 CET Giuseppe D'Angelo via Interest wrote: > Il 06/12/19 09:42, Uwe Rathmann ha scritto: > > Something you can try is to include the moc file at the end of your cpp > > file. This can be done like this: > > > > #include "moc_XYZ.cpp" > > > > This type of construction is at least supported by qmake. > > > > This does not reduce the number of moc runs, but it reduces the number > > of compiler runs. As a rule of thumb for not too large classes I would > > expect, that ~50% of the compile time is spent inside the Qt headers and > > by including the moc file the overall compile time goes down by 33% as > > the headers need to be processed only once. > > This trick is used in several places in Qt itself (look for "includemoc" > in commits). Not only it helps build times but also it produces slightly > better code overall. Heya, On that note, CMake goes one step further and removes the need to do this manually. Using CMake's AUTOMOC feature, CMake will automatically create ONE mocs_compilations.cpp file per target which in turn includes all generated "moc_XYZ.cpp" files. Quoting: "Header files that are not included by an #include "moc_.cpp" statement are nonetheless scanned for Q_OBJECT or Q_GADGET macros. The resulting moc_.cpp files are generated in custom directories and automatically included in a generated /mocs_compilation.cpp file, which is compiled as part of the target." ... from: https://cmake.org/cmake/help/v3.9/prop_tgt/AUTOMOC.html Just as a side note. So if you thought about moving to CMake anyway this might be a good reason for a start. In general switching to e.g. CMake with the Ninja generator will give you better overall build times, esp. on Windows. And you said: > We probably don't strictly need the Q_OBJECT macro in some of those > classes, but I would prefer not to start removing Q_OBJECT unless that's > the last option. I'd rethink that opinion: Adding the Q_OBJECT (and thus inheriting from QObject) everywhere adds the dependency to moc (=> slower compilation time) and has a runtime performance impact (QObject creation is not cheap!). I'd consider only requiring Q_OBJECT where needed, it leads to overall better code. Regards, Kevin > HTH, -- Kevin Funk | kevin.f...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
Il 06/12/19 09:42, Uwe Rathmann ha scritto: Something you can try is to include the moc file at the end of your cpp file. This can be done like this: #include "moc_XYZ.cpp" This type of construction is at least supported by qmake. This does not reduce the number of moc runs, but it reduces the number of compiler runs. As a rule of thumb for not too large classes I would expect, that ~50% of the compile time is spent inside the Qt headers and by including the moc file the overall compile time goes down by 33% as the headers need to be processed only once. This trick is used in several places in Qt itself (look for "includemoc" in commits). Not only it helps build times but also it produces slightly better code overall. HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
On 12/6/19 2:09 AM, Adam Light wrote: Does anyone else have any ideas of how we could change our build to improve moc performance when Windows decides to be "slow"? Something you can try is to include the moc file at the end of your cpp file. This can be done like this: #include "moc_XYZ.cpp" This type of construction is at least supported by qmake. This does not reduce the number of moc runs, but it reduces the number of compiler runs. As a rule of thumb for not too large classes I would expect, that ~50% of the compile time is spent inside the Qt headers and by including the moc file the overall compile time goes down by 33% as the headers need to be processed only once. A side note: the code of Qwt project runs with all Qt versions >= 4.4 and therefore allows to compare the impact of the Qt headers on the compile time. It is some time ago, when I did this, but the differences were significant. IIRC there was a major slowdown around ~4.7 that gets worse during the Qt5 cycle. HTH, Uwe ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
