diff options
author | Christian Kandeler <christian.kandeler@qt.io> | 2023-07-10 15:19:29 +0200 |
---|---|---|
committer | Christian Kandeler <christian.kandeler@qt.io> | 2023-09-05 08:07:50 +0000 |
commit | ae82e039eb74b092604910a1f3f7fa4887397cbc (patch) | |
tree | 69d53083cd122e7089f7dca1cb335a7f7124a2c1 /tests/auto | |
parent | 51e58390f2b34b27d15e7f287353451a6a969a33 (diff) |
Loader: Resolve products in parallel
The resolveProduct() function is now executed for several products
simultaneously, with the (relatively few) accesses to common resources
guarded by mutexes.
Using Qt Creator as a mid-to-large-sized test project, we see the
following changes in the time it takes to resolve the project on some
example machines:
- Linux (36 cores): 10.5s -> 4.8s
- Linux (8 cores): 17s -> 6.5s
- macOS (6 cores): 41s -> 16s
- Windows (8 cores): 20s -> 9s
Unsurprisingly, the speed-up does not scale with the number of
processors, as there are typically lots of inter-product dependencies
and some expensive resources such as Probes are shared globally.
However, we do see a factor of two to three across all the hardware and
OS configuarations, which is a good practical result for users.
Note that running with -j1, i.e. forcing the use of only a single core,
takes the same amount of time everywhere as it did without the patch, so
there is no scheduling overhead in the single-core case.
The results of our benchmarker tool look interesting. Here they are for
qbs and Qt Creator, respectively:
========== Performance data for Resolving ========== (qbs)
Old instruction count: 9121688266
New instruction count: 15736125513
Relative change: +72 %
Old peak memory usage: 84155384 Bytes
New peak memory usage: 187776736 Bytes
Relative change: +123 %
========== Performance data for Resolving ========== (QtC)
Old instruction count: 59901017190
New instruction count: 65227937765
Relative change: +8 %
Old peak memory usage: 621560008 Bytes
New peak memory usage: 761732040 Bytes
Relative change: +22 %
The increased peak memory usage is to be expected, as there are now
several JS engines running in parallel. The instruction count increase
is likely due to a higher amount of deferrals. Importantly, it appears
to go down massively with increased project size, so it does not seem
that the parallelism hides a serious per-thread slowdown.
Change-Id: Ib4d9ca9aa0687c1056ff82f9805b565cc5a35894
Reviewed-by: Ivan Komissarov <ABBAPOH@gmail.com>
Diffstat (limited to 'tests/auto')
-rw-r--r-- | tests/auto/api/tst_api.cpp | 9 |
1 files changed, 1 insertions, 8 deletions
diff --git a/tests/auto/api/tst_api.cpp b/tests/auto/api/tst_api.cpp index 38e9804a3..5042766d9 100644 --- a/tests/auto/api/tst_api.cpp +++ b/tests/auto/api/tst_api.cpp @@ -928,14 +928,7 @@ void TestApi::dependencyOnMultiplexedType() } else { QVERIFY(p.name() == "p2"); ++p2Count; - - // FIXME: This is an odd effect of our current algorithm: We collect the products - // matching the requested type and add Depends items with their names ("p1" in - // this case). Later, the algorithm checking for compatibility regarding the - // multiplexing axes picks the aggregate. However, the aggregate does not have - // a matching type... It's not entirely clear what the real expected - // result should be here. - QCOMPARE(p.dependencies().size(), 2); + QVERIFY(p.dependencies().contains("dep")); } } QCOMPARE(depCount, 1); |