V Tue, 25 Jun 2019 15:46:45 +0000 Arvin Schnell <[email protected]> napsáno:
> On Tue, Jun 25, 2019 at 05:02:43PM +0200, Josef Reidinger 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. > > What actually caused a rebuild of libstorage-ng? libstorage-ng > does not depend on rubocop. Hi, 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 > > help[7]. > > 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 Makefile.am or alternative build tool. Not sure what will probide the most benefits. > > ciao Arvin > Josef [1] https://build.opensuse.org/package/statistics/openSUSE:Factory/libstorage-ng/standard/x86_64 -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
