[Qbs] Improving qbs resolve performance
jochen.ulrich at clausmark.com
Fri Aug 30 10:32:52 CEST 2019
> Is it realistic a depth of 9?
I don't know. In our project, we are facing resolve times of 50s and more. But I didn't check our dependency tree depth yet. :P
But anyway, it shows the resolve behavior depending on the tree depth.
> Looking at your timings, it is still not clear where the bunch of the time is spent for the "withLeafExports/9-2-implicit" use case.
Well it goes into "Handling Products". So it is ModuleLoader::handleProduct().
And there, it could be the ModuleMerger. But speculation is dangerous when discussing about performance.
I also did another test: re-resolving. That is: just touch the "root.qbs" and then resolve again.
And there is one interesting thing: The "Running Probes" step takes nearly the same amount of time:
Handling products took 33s, 333ms.
Running Probes took 18s, 67ms.
5355 probes encountered, 5 configure scripts executed, 5348 re-used from current run, 0 re-used from earlier run.
Property checking took 412ms.
Handling products took 32s, 798ms.
Running Probes took 17s, 543ms.
5355 probes encountered, 0 configure scripts executed, 0 re-used from current run, 5355 re-used from earlier run.
Property checking took 409ms.
I would have expected that "Running Probes" is way faster in the re-resolve case.
Am 30.08.19, 02:07 schrieb "Christian Gagneraud" <chgans at gmail.com>:
On Fri, 30 Aug 2019 at 11:01, Jochen Ulrich <jochen.ulrich at clausmark.com> wrote:
> I want to follow up on this topic:
I had to check the archives and re-read the whole thread!
> I created scripts to generate a Qbs project of a specified size.
> Then, I created a few projects and measured the resolve time.
Nice one. Maybe it would be nice to automate the data collection, this
way it might be interesting to plot the various measurement versus
tree depth and/or child count and/or product count. Just to see if we
have something linear or logarithmic.
Or maybe that's a job for a C++ benchmark...
> Bottom line:
> Exporting dependencies significantly slows down the resolving.
> It is better to explicitly depend on the needed modules instead of having another module export the dependency.
> It’s a trade-off between having to write more “Depends” items vs. slower resolving.
Good to know, But the Export/Depends has definitely it's use, you
don't need to track nested dependencies.
Is it realistic a depth of 9?
Looking at your timings, it is still not clear where the bunch of the
time is spent for the "withLeafExports/9-2-implicit" use case.
More information about the Qbs