Re: make check / dbgutil performance ...

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