minutes of ESC call ...

[Michael Meeks]

On Fri, 2015-05-29 at 02:37 +0200, Bjoern Michaelsen wrote:
> On Thu, May 28, 2015 at 10:40:40PM +0200, Bjoern Michaelsen wrote:
> > And with this I see a lot of processes running parallel till the end. This
> > suggests to me that the stuff is quite parallelized -- however none of the
> > testing threads seem to be CPU-bound rather the Java-stuff seems to be IO bound
> > (for IPC?)

	That's my experience too - lots of latency and low CPU usage; I had
hoped that we could rip a lot of the 'sleep's out of the JUnit tests -
there are still a ton of 'sleep (1)' type things going on in there. IIRC
there was even an easy-hack for that. With the equivalent of this
python:

def initIdle(oSM):
    global toolkit
    toolkit = oSM.createInstance("com.sun.star.awt.Toolkit")
    if toolkit is None:
        print ("Failed to fetch toolkit", file=sys.stderr)

def processIdle():
    global toolkit
    toolkit.processEventsToIdle()

	And the new Idle handler work - I think we should be able to bin all
the sleeps and turn them into a simple IPC round-trip that forces all
pending jobs to run. IIRC there is even an easy-hack for that somewhere;
clearly "sleep 1" defeats even the fastest processor.

	A bigger benefit of that would perhaps be to ensure that there is no
excuse for low CPU usage there - and isolating any remaining latency /
performance problems to the binary-UNO IPC impl.

> good ol' big Bertha with two Opteron 6272s has 32 cores ...
...
> brings 'make check' down to 2m6s on big Bertha. For comparison:
...
> there is no excuse to not run 'make check' anymore at least before
>  pushing -- if there ever was one.

	It is clearly great to run 'make check' before pushing (just fixing
some results from CI) - however, to assume that everyone has a 32 core
machine (I have 4 not-so-strong cores) 32/4 * 2m -> 16m (not so far from
15 minutes ;-).

	The fact that you improved parallelism and shortened longest paths for
the tests is great for those with strong machines - that is far from all
of our contributors; I also quite like to use some of my CPU to read
mail, compile other things etc. ;-)

	But - anyhow; of course its really great to see this sped up.

	ATB,

		Michael.

-- 
 michael.meeks at collabora.com  <><, Pseudo Engineer, itinerant idiot