re-ordering "make subsequentcheck" for performance

[Stephan Bergmann]

On 07/11/2012 03:39 PM, Noel Grandin wrote:
> I'm sitting here with a 6-core monster of a machine, and watching it
> idle away
> (top says 90% idle, iotop says basically nothing is happening)
> as it gently processes the [SCK] stages of "make subsequentcheck".
>
> I've tried cranking up --with-max-jobs to 18 and --with-num-cpus to 12,
> but that doesn't seem to be helping much.
>
> I think what might be happening is that longer-running tests are towards
> the end, and I'm suffering from a "long tail" effect.
> I think it ought to be possible to speed this up a bit by re-ordering
> the longer running stuff towards the beginning.
>
> Where in the build scripts should I look to change this ordering?

IIUC, the order the tests are run is implicit in how make orders 
execution of targets.  (From my experience, the toolkit/unoapi test is 
rather long-running and somewhat unfortunately gets scheduled towards 
the end.)

We used to have a CHECK_PARALLELISM variable to be able to specify the 
parallelism of executing those tests independent of 
--with-max-jobs/--with-num-cpus (as each such test tends to produce 
little load, so it can be beneficial to run ~many of them per cpu), but 
that apparently got lost with 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=8a310e3521db1f9a15a7ec32b3171c4969c461be> 
"moved some more targets to gbuild."

Stephan