Enable UNITY_BUILD=ON on qgis_core (37% to 50% faster builds), qgis_gui (50% faster builds), qgis_analysis (3.7x faster) #59669

rouault · 2024-11-30T02:46:15Z

On top of PR #59667

Besides much faster compilation time, we also get massive reduction of the size of build artifacts !!!

That said UNITY_BUILD tend to be fragile. To debate if we want to enable them conditionally or not

On Ubuntu 22.04, QT5, debug builds

With just precompiled qgis.h header:

$ time make -j12 qgis_core
real	6m3.472s
user	59m3.835s
sys	5m22.424s

$ du -c src/core | tail -n 1
2137448	total

$ ll ./output/lib/libqgis_core.so.3.41.0 
-rwxr-xr-x 1 root root 598395456 Nov 30 00:56 ./output/lib/libqgis_core.so.3.41.0*

vs with UNITY_BUILD, 37% faster:

$ time make -j12 qgis_core
real	3m45.263s
user	24m3.530s
sys	1m48.078s

$ du -c src/core | tail -n 1
944580	total

$ ll ./output/lib/libqgis_core.so.3.41.0 
-rwxr-xr-x 1 root root 278469184 Nov 30 03:35 ./output/lib/libqgis_core.so.3.41.0*

On Fedora:rawhide, QT6, debug builds

With just precompiled qgis.h header:

$ time ninja qgis_core
real	10m35.657s
user	97m51.161s
sys	7m59.564s

$ du -c src/core | tail -n 1
3028420	total

$ ll ./output/lib/libqgis_core.so.3.41.0 
-rwxr-xr-x 1 root root 825732184 Nov 30 00:38 ./output/lib/libqgis_core.so.3.41.0

vs with UNITY_BUILD, 50% faster:

$ time ninja qgis_core
real	5m13.791s
user	41m42.880s
sys	3m8.986s

$ du -c src/core | tail -n 1
1333320	total

$ ll ./output/lib/libqgis_core.so.3.41.0 
-rwxr-xr-x 1 root root 389392736 Nov 30 03:05 ./output/lib/libqgis_core.so.3.41.0

github-actions · 2024-11-30T04:33:39Z

🪟 Windows builds

Download Windows builds of this PR for testing.
Debug symbols for this build are available here.
(Built from commit 63c9f38)

🪟 Windows Qt6 builds

Download Windows Qt6 builds of this PR for testing.
(Built from commit 63c9f38)

nyalldawson · 2024-11-30T06:06:34Z

My gut feeling is this should be conditional, defaulting to off but on for ci. But I'm interested in other's thoughts!

m-kuhn · 2024-11-30T10:23:50Z

Interesting.
I don't have experience with this.

My gut feeling is this should be conditional, defaulting to off but on for ci.

I agree, from a short read about the topic there's a risk of semantic changes (dangerous for release) and incremental builds may even suffer performance wise (?)

As we do a lot of ccache for tests too, I wonder about the real effect there, is that still 37-50% faster?

rouault · 2024-11-30T12:03:48Z

I don't have experience with this.

I've done that for GDAL and PROJ. Part of our CI use unity builds, part regular builds. The default is not unity builds, out of caution. I initially hit bugs, most of them caught at compilation time, a few residual ones by test suite (I've a memory of one that was really tricky to track down. It turned out to be due to code that relied on inherently undefined behavior, and with a unity build, the optimizer used that to optimize away the wrong code... OSGeo/gdal@7104ec6). So I'm inclined to make it conditioned by option(ENABLE_UNITY_BUILDS "Enable Unity builds (EXPERIMENTAL. Not recommended for production builds)" OFF) for QGIS

As we do a lot of ccache for tests too, I wonder about the real effect there, is that still 37-50% faster?

That's a good question. It will depend on the content of pull requests. Typically a unity build reduces the number of compilation units by 8 or so. So if you have a pull request that touches only one .cpp file, at least 7 others will also be rebuilt. So that's something like going from a 1 second incremental build time to 8 seconds, considering all other are ccached. Not a big deal for CI purposes... But that might be a big deal for a developer wanting to quickly iterate during development and if struggling with some compilation errors (like fighting with templates, etc...)
Other CI use cases might be qgis.h being modified and causing a full rebuild, in that case that's going to be a clear win. My feeling is that in average it should be beneficial.
In non CI use cases, using unity builds might be beneficial for a moderately active QGIS developer or enthusiast user that doesn't develop frequently but "git pull && ninja" once a week to keep track. Updating every week generally pull changes that causes a full rebuild.

m-kuhn · 2024-11-30T12:15:06Z

Sounds reasonable 👍

rouault · 2024-11-30T12:39:01Z

I've pushed extra changes:

introducing ENABLE_UNITY_BUILDS CMake variable, and defaulting it to OFF
using it in src/core/CMakeLists.txt
making the few needed changes to enable qgis_gui unity builds, and enabling qgis_gui unity builds if ENABLE_UNITY_BUILDS
setting ENABLE_UNITY_BUILDS=ON for run-test.yml

For qgis_gui, unity builds for qt5 are 60% faster (from 5m 45s clock time down to 2m 12s, and 53m30s total cpu time down to 18m 8s)

m-kuhn · 2024-11-30T12:44:56Z

I'd love to see the impact on the windows-qt6 builds (MSVC is notoriously slow)

rouault · 2024-11-30T15:40:22Z

fedora:rawhide, qt6, qgis_gui, unity: real 6m30, user 45m20s, sys 5m1s
fedora:rawhide, qt6, qgis_gui, regular: real 12m48, user 108m33, sys 10m36s

ubuntu:22.04, qt5, qgis_analysis, unity: real 0m42s, user 5m39s, sys 0m26s
ubuntu:22.04, qt5, qgis_analysis, regular: real 2m37s, user 26m25, sys 2m18s

I'd love to see the impact on the windows-qt6 builds

I've enabled it for windows-qt6 as well and the results are quite spectacular!

master: 3h 13m
PR 59667 (precompiled headers): 2h 2m
this PR (precompiled headers + unity builds for core, gui and analysis): 1h 24m

(MSVC is notoriously slow)

has clang for Windows been considered? It has the same C/C++ ABI as MSVC: https://clang.llvm.org/docs/MSVCCompatibility.html.

m-kuhn · 2024-11-30T15:51:24Z

I've enabled it for windows-qt6 as well and the results are quite spectacular!

master: 3h 13m

PR 59667 (precompiled headers): 2h 2m

this PR (precompiled headers + unity builds for core, gui and analysis): 1h 24m

Wow! 🐝💨

With ccache working on current master ~40m

(MSVC is notoriously slow)

has clang for Windows been considered? It has the same C/C++ ABI as MSVC: https://clang.llvm.org/docs/MSVCCompatibility.html

I've used it in the past and it performed better. I had troubles in other scenarios. I don't recall the details unfortunately, but it might be worth another try.

m-kuhn · 2024-11-30T16:11:28Z

@rouault I enabled ccache for testing reasons, I hope you don't mind

…Woverloaded-virtual warning related to syncToLayer() method

m-kuhn · 2024-12-01T10:16:52Z

Win Rebuild with ccache: 67m

rouault · 2024-12-01T14:58:55Z

Win Rebuild with ccache: 67m

I found a master windows-qt6 build (https://github.com/qgis/QGIS/actions/runs/12070745214/job/33660951496) done by auto sipify which was 48 minute long, with following ccache stats:

Cacheable calls:   3162 / 3240 (97.59%)
    Hits:            2994 / 3162 (94.69%)
      Direct:        2819 / 2994 (94.15%)
      Preprocessed:   175 / 2994 ( 5.85%)
    Misses:           168 / 3162 ( 5.31%)
  Uncacheable calls:   78 / 3240 ( 2.41%)
  Local storage:
    Cache size (GB):  1.0 /  1.0 (99.86%)
    Cleanups:          33
    Hits:            2994 / 3162 (94.69%)
    Misses:           168 / 3162 ( 5.31%)

and the latest build of this PR:

  Cacheable calls:   669 / 1090 (61.38%)
   Hits:            661 /  669 (98.80%)
     Direct:        567 /  661 (85.78%)
     Preprocessed:   94 /  661 (14.22%)
   Misses:            8 /  669 ( 1.20%)
 Uncacheable calls: 421 / 1090 (38.62%)
 Local storage:
   Cache size (GB): 0.2 /  1.0 (16.08%)
   Hits:            661 /  669 (98.80%)
   Misses:            8 /  669 ( 1.20%)

So for some reason unity builds would reduce the number of cacheable calls. The good and bad news is that it isn't a Windows specific behavior. I unfortunately reproduce that on ubuntu:22.04 I get a 0% cache hit when rebuilding qgis_core...

rouault · 2024-12-01T15:39:29Z

hum trying on ubuntu 22.04, the bad news is that the incompatibility with ccache isn't related to unity builds but with the precompiled headers. We have propably merged #59667 too soon.
The good news is that I've fixed it finding in the ccache manual (https://ccache.dev/manual/4.10.2.html#_precompiled_headers), that you need to run "ccache --set-config sloppiness=pch_defines,time_macros". I confirm this works fine now with unity_builds on my system. I've added a commit for that

… setting 'ccache -set-config sloppiness=pch_defines,time_macros'

rouault · 2024-12-01T19:16:15Z

windows-qt6 build: first run 71 minutes, re-run 72 minutes with 65% cache it and 92% cacheable calls
build 22.04 qt5: first run 35 minutes, re-run in 33 minutes with a 78% ccache hit and 78% cacheable calls (I should have noted the one in the first run...)
build 39 qt6 : first run 1h 2minute, second in 1h 3 with also a 78% ccache hit and 78% cacheable calls

That said, on fedora:rawhide qt6, qgis_core builds with precompiled headers (independently of whather unity builds are enabled) do not trigger any ccache hits when wiping off build/src/core, in particular when removing the .gch precompiled header. It seems that its regeneration makes it to be considered as something non cacheable. Not sure if the issue is relate to the version of cmake, ccache, qt6, g++ or something else, compared to ubuntu 22.04 where things work just perfectly.

I'm not sure what conclusion to draw from that. For developer use cases, where you don't normally wipe off your build directory, even the issue with fedora:rawhide qt6 shouldn't be much a practical issue. But for CI builds this is more annoying.
So in the current situation, for QT6 builds we should probably disable pre-compiled headers on CI (unity builds themselves are fine)

nyalldawson · 2024-12-01T20:57:19Z

@rouault does it help if you crank up the ccache max size? I've always found the default (on fedora at least) to be much too small

rouault · 2024-12-01T21:30:58Z

does it help if you crank up the ccache max size? I've always found the default (on fedora at least) to be much too small

no, that's not the issue. My cache has plenty of free space. The issue is that with ccache and/or g++ of fedora:rawhide the cmake_pch.hxx.gch generated file corresponding to the precompiler header causes an internal error to ccache and thus is regenerated at every fresh build when the .gch file is not already present on the file system, which, combined with the fact that gcc doesn't regenerate binary identical .gch files on repeated invocations on identical inputs (that applies even in trivial cases where the precompiled header contains nothing!), causes non-hits.

Cf:

``` [root@50a8f20149e6 build_fedora_qt6]# ccache -z Statistics zeroed ``` ``` [root@50a8f20149e6 build_fedora_qt6]# ccache /usr/bin/c++ "-DCMAKE_SOURCE_DIR=\"/home/even/qgis/qgis\"" -DQT_CONCURRENT_LIB -DQT_CORE5COMPAT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_TO_ASCII -DQT_NO_DEPRECATED_WARNINGS -DQT_NO_FOREACH -DQT_POSITIONING_LIB -DQT_PRINTSUPPORT_LIB -DQT_SERIALPORT_LIB -DQT_SQL_LIB -DQT_SVG_LIB -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -DSIP_VERSION=0x060806 "-DTEST_DATA_DIR=\"/home/even/qgis/qgis/tests/testdata\"" -DWITH_COPC -DWITH_EPT -D_HAVE_PTHREAD_ -Dqgis_core_EXPORTS -I/home/even/qgis/qgis/build_fedora_qt6/src/core/qgis_core_autogen/include -I/home/even/qgis/qgis/build_fedora_qt6 -I/home/even/qgis/qgis/external/poly2tri -I/home/even/qgis/qgis/src/core/providers/ept -I/home/even/qgis/qgis/src/core/providers/copc -I/home/even/qgis/qgis/src/core/providers/vpc -I/home/even/qgis/qgis/build_fedora_qt6/src/core -I/home/even/qgis/qgis/external/meshOptimizer -I/home/even/qgis/qgis/src/core -I/home/even/qgis/qgis/src/core/3d -I/home/even/qgis/qgis/src/core/actions -I/home/even/qgis/qgis/src/core/annotations -I/home/even/qgis/qgis/src/core/auth -I/home/even/qgis/qgis/src/core/browser -I/home/even/qgis/qgis/src/core/callouts -I/home/even/qgis/qgis/src/core/classification -I/home/even/qgis/qgis/src/core/diagram -I/home/even/qgis/qgis/src/core/dxf -I/home/even/qgis/qgis/src/core/editform -I/home/even/qgis/qgis/src/core/effects -I/home/even/qgis/qgis/src/core/elevation -I/home/even/qgis/qgis/src/core/expression -I/home/even/qgis/qgis/src/core/externalstorage -I/home/even/qgis/qgis/src/core/fieldformatter -I/home/even/qgis/qgis/src/core/geometry -I/home/even/qgis/qgis/src/core/geocoding -I/home/even/qgis/qgis/src/core/gps -I/home/even/qgis/qgis/src/core/labeling -I/home/even/qgis/qgis/src/core/labeling/rules -I/home/even/qgis/qgis/src/core/layertree -I/home/even/qgis/qgis/src/core/layout -I/home/even/qgis/qgis/src/core/locator -I/home/even/qgis/qgis/src/core/maprenderer -I/home/even/qgis/qgis/src/core/mesh -I/home/even/qgis/qgis/src/core/metadata -I/home/even/qgis/qgis/src/core/network -I/home/even/qgis/qgis/src/core/numericformats -I/home/even/qgis/qgis/src/core/painting -I/home/even/qgis/qgis/src/core/pal -I/home/even/qgis/qgis/src/core/pdf -I/home/even/qgis/qgis/src/core/plot -I/home/even/qgis/qgis/src/core/pointcloud -I/home/even/qgis/qgis/src/core/pointcloud/expression -I/home/even/qgis/qgis/src/core/processing -I/home/even/qgis/qgis/src/core/processing/models -I/home/even/qgis/qgis/src/core/proj -I/home/even/qgis/qgis/src/core/project -I/home/even/qgis/qgis/src/core/providers -I/home/even/qgis/qgis/src/core/providers/arcgis -I/home/even/qgis/qgis/src/core/providers/memory -I/home/even/qgis/qgis/src/core/providers/gdal -I/home/even/qgis/qgis/src/core/providers/ogr -I/home/even/qgis/qgis/src/core/providers/meshmemory -I/home/even/qgis/qgis/src/core/providers/sensorthings -I/home/even/qgis/qgis/src/core/raster -I/home/even/qgis/qgis/src/core/renderer -I/home/even/qgis/qgis/src/core/scalebar -I/home/even/qgis/qgis/src/core/settings -I/home/even/qgis/qgis/src/core/sensor -I/home/even/qgis/qgis/src/core/stac -I/home/even/qgis/qgis/src/core/symbology -I/home/even/qgis/qgis/src/core/textrenderer -I/home/even/qgis/qgis/src/core/tiledscene -I/home/even/qgis/qgis/src/core/validity -I/home/even/qgis/qgis/src/core/vector -I/home/even/qgis/qgis/src/core/vectortile -I/home/even/qgis/qgis/src/core/web -I/home/even/qgis/qgis/external -I/home/even/qgis/qgis/external/delaunator-cpp -I/home/even/qgis/qgis/external/kdbush/include -I/home/even/qgis/qgis/external/nmea -I/home/even/qgis/qgis/external/rtree/include -I/home/even/qgis/qgis/external/tinygltf -isystem /usr/include/qt6/QtCore -isystem /usr/include/qt6 -isystem /usr/include/qt6/QtGui -isystem /usr/include/qt6/QtDBus -isystem /usr/include/qt6/QtXml -isystem /usr/include/qt6/QtWidgets -isystem /usr/include/qt6/QtSvg -isystem /usr/include/qt6/QtNetwork -isystem /usr/include/qt6/QtSql -isystem /usr/include/qt6/QtConcurrent -isystem /usr/include/qt6/QtCrypto -isystem /usr/include/qt6/QtSerialPort -isystem /usr/include/qt6/QtPrintSupport -isystem /usr/lib64/qt6/mkspecs/linux-g++ -isystem /usr/include/geos -isystem /usr/include/gdal -isystem /usr/include/qt6/QtCore5Compat -isystem /usr/include/qt6/QtPositioning -Wall -Wextra -Wno-long-long -Wformat-security -Wno-strict-aliasing -Wnon-virtual-dtor -Wno-redundant-move -Wno-misleading-indentation -Wno-deprecated-copy -g -std=gnu++17 -fPIC -fvisibility=hidden -x c++-header -include /home/even/qgis/qgis/build_fedora_qt6/src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx -MD -MT src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx.gch -MF src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx.gch.d -o src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx.gch -c /home/even/qgis/qgis/build_fedora_qt6/src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx.cxx ``` ``` [root@50a8f20149e6 build_fedora_qt6]# ccache -s Cacheable calls: 0 / 1 ( 0.00%) Hits: 0 Direct: 0 Preprocessed: 0 Misses: 0 Errors: 1 / 1 (100.0%) Local storage: Cache size (GiB): 2.2 / 5.0 (44.24%) ```

I've enable ccache debugging with "ccache --set-config=debug=true" and "export CCACHE_LOGFILE=/tmp/ccache.log" but nothing in the log seems actionable.
The .gch file in the case of qt6 is 166 MB large compared to 126 MB with qt5

nyalldawson · 2024-12-01T22:38:33Z

@rouault

That said, on fedora:rawhide qt6, qgis_core builds with precompiled headers (independently of whather unity builds are enabled) do not trigger any ccache hits when wiping off build/src/core, in particular when removing the .gch precompiled header. It seems that its regeneration makes it to be considered as something non cacheable. Not sure if the issue is relate to the version of cmake, ccache, qt6, g++ or something else, compared to ubuntu 22.04 where things work just perfectly.

I just tested F41, qt5 build and I get a 100% hit rate (after the ccache config change) after a build folder wipe-and-rebuild:

Cacheable calls:   4274 /  4854 (88.05%)
  Hits:            4274 /  4274 (100.0%)
    Direct:        4182 /  4274 (97.85%)
    Preprocessed:    92 /  4274 ( 2.15%)
  Misses:             0 /  4274 ( 0.00%)
Uncacheable calls:  580 /  4854 (11.95%)
Local storage:
  Cache size (GB):  3.1 / 100.0 ( 3.10%)
  Hits:            4274 /  4274 (100.0%)
  Misses:             0 /  4274 ( 0.00%)

For F41, qt6 build:

Cacheable calls:   4010 /  4564 (87.86%)
  Hits:            3396 /  4010 (84.69%)
    Direct:        3292 /  3396 (96.94%)
    Preprocessed:   104 /  3396 ( 3.06%)
  Misses:           614 /  4010 (15.31%)
Uncacheable calls:  554 /  4564 (12.14%)
Local storage:
  Cache size (GB):  6.3 / 100.0 ( 6.26%)
  Hits:            3396 /  4010 (84.69%)
  Misses:           614 /  4010 (15.31%)

rouault · 2024-12-01T23:31:17Z

For F41, qt6 build:

I don't know what's specific with qt6 and ccache. But I found that sometimes I manage to get hits for .pch regeneration by setting the ccache config "sloppiness = include_file_ctime, include_file_mtime, pch_defines, time_macros" (the include_file_ctime and _mtime speciically, because the pch_defines,time_macros are needed for qt5 as well), but that's not always sufficient. I don't manage to understand the exact circumstances where I get hits or misses
With CCACHE_LOGFILE=/tmp/ccache.log, looking at the log files when there are misses related to the .gch generation, I see lines like
[2024-12-01T22:46:48.503910 96569] Precompiled header includes /home/even/qgis/qgis/build_fedora_qt6/src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx, which has a new mtime
[2024-12-01T22:46:48.503942 96569] Precompiled header includes /home/even/qgis/qgis/build_fedora_qt6/src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx, which has a new mtime
[2024-12-01T22:46:48.503962 96569] Precompiled header includes /home/even/qgis/qgis/build_fedora_qt6/src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx, which has a new mtime
[2024-12-01T22:46:48.503979 96569] Precompiled header includes /home/even/qgis/qgis/build_fedora_qt6/src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx, which has a new mtime
[2024-12-01T22:46:48.503994 96569] Precompiled header includes /home/even/qgis/qgis/build_fedora_qt6/src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx, which has a new mtime
[2024-12-01T22:46:48.504010 96569] Precompiled header includes /home/even/qgis/qgis/build_fedora_qt6/src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx, which has a new mtime
[2024-12-01T22:46:48.504025 96569] Precompiled header includes /home/even/qgis/qgis/build_fedora_qt6/src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx, which has a new mtime
[2024-12-01T22:46:48.504039 96569] Precompiled header includes /home/even/qgis/qgis/build_fedora_qt6/src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx, which has a new mtime
[2024-12-01T22:46:48.504054 96569] Precompiled header includes /home/even/qgis/qgis/build_fedora_qt6/src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx, which has a new mtime
[2024-12-01T22:46:48.504069 96569] Precompiled header includes /home/even/qgis/qgis/build_fedora_qt6/src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx, which has a new mtime
[2024-12-01T22:46:48.504084 96569] Precompiled header includes /home/even/qgis/qgis/build_fedora_qt6/src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx, which has a new mtime
[2024-12-01T22:46:48.504099 96569] Precompiled header includes /home/even/qgis/qgis/build_fedora_qt6/src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx, which has a new mtime
[2024-12-01T22:46:48.504113 96569] Precompiled header includes /home/even/qgis/qgis/build_fedora_qt6/src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx, which has a new mtime
And at each new attempt (while wiping of ${build_dir}/src/core), one extra such line is added. It looks like ccache is confused by .gch. But why is that qt6 specific is a total mystery...

rouault · 2024-12-02T01:32:07Z

ok, I finally figured out the magic needed to make ccache works properly on fedora:rawhide with QT6 and /usr/bin/c++ being the compiler which ccache doesn't understand out-of-the-box to be g++, which requires to set a ccache config item. Let's see if the changes also help for Windows Qt6...

…MSVC, as ccache doesn't support that

rouault · 2024-12-02T03:58:26Z

I found ccache/ccache#1383 which indicates that there's no point in enabling precompiled headers with the combo MSVC + ccache, so I've aded a commit to disable them in that situation

github-actions bot added this to the 3.42.0 milestone Nov 30, 2024

rouault force-pushed the unity_build_core branch 2 times, most recently from 013ab87 to d93ff88 Compare November 30, 2024 03:07

rouault changed the title ~~Enable UNITY_BUILD=ON on qgis_core for 37% faster builds~~ Enable UNITY_BUILD=ON on qgis_core for 37% to 50% faster builds Nov 30, 2024

rouault force-pushed the unity_build_core branch 2 times, most recently from ba4c5f5 to da98dd1 Compare November 30, 2024 03:36

rouault force-pushed the unity_build_core branch 2 times, most recently from d45a8c1 to ff708f6 Compare November 30, 2024 12:56

rouault changed the title ~~Enable UNITY_BUILD=ON on qgis_core for 37% to 50% faster builds~~ Enable UNITY_BUILD=ON on qgis_core (37% to 50% faster builds) and qgis_gui (50% faster builds) Nov 30, 2024

rouault force-pushed the unity_build_core branch 3 times, most recently from 5eda51b to 2680653 Compare November 30, 2024 14:00

rouault force-pushed the unity_build_core branch from 2680653 to 0cd7f33 Compare November 30, 2024 15:40

rouault changed the title ~~Enable UNITY_BUILD=ON on qgis_core (37% to 50% faster builds) and qgis_gui (50% faster builds)~~ Enable UNITY_BUILD=ON on qgis_core (37% to 50% faster builds), qgis_gui (50% faster builds), qgis_analysis (3.7x faster) Nov 30, 2024

rouault force-pushed the unity_build_core branch from 0cd7f33 to 46212e0 Compare November 30, 2024 16:07

nyalldawson approved these changes Nov 30, 2024

View reviewed changes

rouault added 4 commits December 1, 2024 00:49

[OGR provider] Fix inappropriate use of OGREnvelope3D

a16c9be

qgsgml/qgsgmlshema: avoid redefining same constant

db65e95

src/core/mesh: factor a common method

820e75e

src/core/geocoding: avoid same name for global constant

2c953ff

rouault and others added 12 commits December 1, 2024 00:49

QgsMapLayerConfigWidget/QgsRendererRasterPropertiesWidget: suppress -…

6d20384

…Woverloaded-virtual warning related to syncToLayer() method

src/gui/editorwidgets: remove unused private members

9d3a9b0

src/gui: use unity builds if ENABLE_UNITY_BUILDS

6015f50

CI: set ENABLE_UNITY_BUILDS=ON for run-test.yml

19509bb

windows-qt6.yml: enable ENABLE_UNITY_BUILDS=ON

a43a076

src/analysis: changes to allow unity builds

878ac1e

src/analysis: use unity builds if ENABLE_UNITY_BUILDS

2469d0b

src/3d: use unity builds if ENABLE_UNITY_BUILDS

057b51d

qgsdwgimporter.h: add import guard

3ac1228

src/app: use unity builds if ENABLE_UNITY_BUILDS

5d8302b

src/server: use unity builds if ENABLE_UNITY_BUILDS

cb3fec0

Update windows-qt6.yml

2ef66b0

rouault force-pushed the unity_build_core branch from 1621b21 to 2ef66b0 Compare November 30, 2024 23:50

rouault force-pushed the unity_build_core branch 2 times, most recently from 9340fbf to 4011529 Compare December 1, 2024 15:46

Due to the introduction of precompiled headers, ccache builds require…

075ea95

… setting 'ccache -set-config sloppiness=pch_defines,time_macros'

rouault force-pushed the unity_build_core branch from 4011529 to 075ea95 Compare December 1, 2024 16:01

Fix issue with .gch ccach'ing not working with QT6 and gcc

116f81b

rouault force-pushed the unity_build_core branch from 30994ec to 116f81b Compare December 2, 2024 01:48

Do not enable pre-compiled headers when ccache is available and with …

63c9f38

…MSVC, as ccache doesn't support that

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Enable UNITY_BUILD=ON on qgis_core (37% to 50% faster builds), qgis_gui (50% faster builds), qgis_analysis (3.7x faster) #59669

Enable UNITY_BUILD=ON on qgis_core (37% to 50% faster builds), qgis_gui (50% faster builds), qgis_analysis (3.7x faster) #59669

rouault commented Nov 30, 2024 •

edited

Loading

github-actions bot commented Nov 30, 2024 •

edited

Loading

nyalldawson commented Nov 30, 2024

m-kuhn commented Nov 30, 2024

rouault commented Nov 30, 2024

m-kuhn commented Nov 30, 2024

rouault commented Nov 30, 2024 •

edited

Loading

m-kuhn commented Nov 30, 2024

rouault commented Nov 30, 2024

m-kuhn commented Nov 30, 2024 •

edited

Loading

m-kuhn commented Nov 30, 2024

m-kuhn commented Dec 1, 2024 •

edited

Loading

rouault commented Dec 1, 2024

rouault commented Dec 1, 2024

rouault commented Dec 1, 2024

nyalldawson commented Dec 1, 2024

rouault commented Dec 1, 2024 •

edited

Loading

nyalldawson commented Dec 1, 2024

rouault commented Dec 1, 2024

rouault commented Dec 2, 2024

rouault commented Dec 2, 2024

Enable UNITY_BUILD=ON on qgis_core (37% to 50% faster builds), qgis_gui (50% faster builds), qgis_analysis (3.7x faster) #59669

Are you sure you want to change the base?

Enable UNITY_BUILD=ON on qgis_core (37% to 50% faster builds), qgis_gui (50% faster builds), qgis_analysis (3.7x faster) #59669

Conversation

rouault commented Nov 30, 2024 • edited Loading

github-actions bot commented Nov 30, 2024 • edited Loading

🪟 Windows builds

🪟 Windows Qt6 builds

nyalldawson commented Nov 30, 2024

m-kuhn commented Nov 30, 2024

rouault commented Nov 30, 2024

m-kuhn commented Nov 30, 2024

rouault commented Nov 30, 2024 • edited Loading

m-kuhn commented Nov 30, 2024

rouault commented Nov 30, 2024

m-kuhn commented Nov 30, 2024 • edited Loading

m-kuhn commented Nov 30, 2024

m-kuhn commented Dec 1, 2024 • edited Loading

rouault commented Dec 1, 2024

rouault commented Dec 1, 2024

rouault commented Dec 1, 2024

nyalldawson commented Dec 1, 2024

rouault commented Dec 1, 2024 • edited Loading

nyalldawson commented Dec 1, 2024

rouault commented Dec 1, 2024

rouault commented Dec 2, 2024

rouault commented Dec 2, 2024

rouault commented Nov 30, 2024 •

edited

Loading

github-actions bot commented Nov 30, 2024 •

edited

Loading

rouault commented Nov 30, 2024 •

edited

Loading

m-kuhn commented Nov 30, 2024 •

edited

Loading

m-kuhn commented Dec 1, 2024 •

edited

Loading

rouault commented Dec 1, 2024 •

edited

Loading