Mailinglist Archive: yast-devel (48 mails)

< Previous Next >
Re: [yast-devel] Build Times Strikes Back
  • From: Josef Reidinger <jreidinger@xxxxxxx>
  • Date: Wed, 26 Jun 2019 10:39:56 +0200
  • Message-id: <20190626103956.6dd9466d@linux-vvcf.privatesite>
V Tue, 25 Jun 2019 15:46:45 +0000
Arvin Schnell <aschnell@xxxxxxxx> napsáno:

On Tue, Jun 25, 2019 at 05:02:43PM +0200, Josef Reidinger wrote:


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.

What actually caused a rebuild of libstorage-ng? libstorage-ng
does not depend on rubocop.

it really does not depend, I am just checking build times when waiting for full
rebuild due to changes in yast2-devtools (that does not trigger libstorage-ng
rebuild) and want to share what I found.

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.

The build times look high to me. On my machine 'osc build' takes
less than 500s (uses make -j8).

Maybe some workers specific? I check more places where it builds and in factory
it took 2261 seconds[1]. Maybe disk seeking? or less powerfull cpu? In this
case it is j4, so still not two times slower then your j8. I found that peek
memory usage is 2708 Mbyte ( visible in [1] ), so maybe just adding constrain
file that require at least 4GiB of RAM can help to prevent swaping and also
helps with caching of disk content?

- 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.

Both the Pyhton and Ruby bindings could be build in separate
packages. But that would (likely) have to downside that the
bindings cannot be build in parallel with the library.

Probably not worth it as yast2-storage-ng depends on ruby-bindings, so still
whole yast stack will be blocked.

- 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

That should work. I have a hackish bash script that does so (even
in parallel to the rest) and uses about 6m.

6m just bindings? or whole build? maybe it would be worth try. Or maybe really
try that less hacking non recursive or alternative build tool. Not
sure what will probide the most benefits.

ciao Arvin


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

< Previous Next >