Mailinglist Archive: yast-devel (48 mails)

< Previous Next >
[yast-devel] Build Times Strikes Back
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
- - 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?


To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >