[Libreoffice-qa] minutes of ESC call ...
michael.meeks at collabora.com
Fri May 29 02:02:56 PDT 2015
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
toolkit = oSM.createInstance("com.sun.star.awt.Toolkit")
if toolkit is None:
print ("Failed to fetch toolkit", file=sys.stderr)
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.
michael.meeks at collabora.com <><, Pseudo Engineer, itinerant idiot
More information about the Libreoffice-qa