Hi, On Fri, Jun 05, 2015 at 11:56:09AM +0100, Michael Meeks wrote: > Without dbgutil we get: > > real 12m45.145s > user 28m47.321s > sys 2m34.849s > > Which is better, but still not 3x minutes.
On a slow machine, things are slow. How does it compare to just relinking LibreOffice libs once on that machine? Thats IMHO a goal: to be roughly in the same ballpark. > Then again - I don't have an 8x core i7 - which no matter how > apparently cheap they are 2nd hand doesn't seem to me that reasonable. Why? It would be an interesting thing to ask around for with LibreOffice developers, but my gut feeling is that the 'has to compile on the notebook that I take aorund the world'-requirement is more one from sponsored developers, while our volunteer contributors often do their compiles at home on a desktop machine ... > So - it seems to me that we could usefully invest in improving 'make > check' performance; not least by loosing 'sleeps' - I guess more > profiling is in order. Maybe, maybe not. If a 'make check PARALLELISM=9999' is slower/faster by roughly the same ratio between machines, it seems it becomes CPU-bound rather quickly. The numbers from my other mail: make check : 4m36.399s make check PARALLELISM=9999: 3m 9.598s suggest that there is not much to gain beyond 8x parallelism -- thus there is not much idling then. Also you said the last processes hanging around for you were cppunittesters processes, which should be idlefree. > Oh ! and - I suspect the ~3x slower dbgutil issue can be fixed with > this easy hack: > > https://bugs.documentfoundation.org/show_bug.cgi?id=91872 > > Which is also rather easy I hope. Yep, there is some hope there. Best, Bjoern _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
