Hi, today when I am waiting for OBS to build new ci container for testing new rubocop I check how situation changes after our last effort to reduce build time of yast stack. I use our old tool [1] and there is also old data[2]. So I can compare critical path ( which is the most interesting, as it count minimum time needed to build yast stack if we have same machines, but in unlimited amount ). So how it changes? critical path: - total time: 1780 + total time: 3452 path: - - yast2-schema [141s] - - autoyast2 [168s] - - yast2-update [143s] - - yast2-packager [75s] - - yast2-storage [226s] - - yast2-perl-bindings [236s] - - yast2-ruby-bindings [181s] - - yast2-ycp-ui-bindings [107s] - - yast2-core [426s] - - yast2-devtools [77s] + - yast2-schema [134s] + - yast2-ntp-client [93s] + - autoyast2 [723s] + - yast2-installation [721s] + - yast2-network [171s] + - yast2-packager [93s] + - yast2-storage-ng [186s] + - libstorage-ng [1331s] The first think that is visible immediatelly that it increase a lot. From cca 30 minutes to almost 60 minutes ( so no surprise I am waiting for new release :) So I check more deeply some values, as some times looks strange. Sometimes it looks like strange behavior of OBS because total time is much bigger then steps like for yast2-installation[3] or autoyast2[4], but for libstrorage-ng it looks like real data[5]. So I check if libstorage-ng is not unlucky and simply does not hit weak machine, but it builds with -j6 which is not bad from my POV. So I do quick analyse where it spends time ( from log [6]): total: 1327s unpacking: 1s compilation (configure + make all): 921s ( doxygen: 10s, translations: 0s, bindings: 542s, ) install: 8s deduplication: 2s tests: 260s To compare, old libstorage need in total 549 seconds. So there is really slow down in build time. Question is how to speed up building process? Any ideas? I think 20 minutes for the initial building stone of all yast modules is too much. Few wild ideas: - create libstorage-ng-bootstrap that will be used for building yast2-storage-ng. That bootstrap will skip tests and pythong bindings and maybe even compile with less aggresive g++ options, which should help a lot. And of course then proper package is build that will have all this. - build python and ruby bindings in parallel. Is it doable? Or ideally do it in parallel to other compilation tasks. ( not sure if it does not hit us back with disk seeking ). Here non-recursive feature of autotools can help[7]. Any other idea that can help? Josef [1] https://github.com/mvidner/rpm-build-dependencies [2] https://github.com/mvidner/rpm-build-dependencies/blob/master/yast_deps.yaml [3] https://build.opensuse.org/package/statistics/YaST:Head/yast2-installation/o... [4] https://build.opensuse.org/package/statistics/YaST:Head/autoyast2/openSUSE_F... [5] https://build.opensuse.org/package/statistics/YaST:Head/libstorage-ng/openSU... [6] https://build.opensuse.org/build/YaST:Head/openSUSE_Factory/x86_64/libstorag... [7] https://autotools.io/automake/parallel.html -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org