On wto, cze 25, 2019 at 5:02 PM, Josef Reidinger <[email protected]>
wrote:
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?
I would be curious about how quick meson/ninja would as a replacement
for configure/make all. It promises to be quite a bit faster compared to
other tools ;)
LCP [Stasiek]
https://lcp.world
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
