Profiling parallel tests

[Nicholas Clark]

On Mon, Aug 18, 2008 at 06:29:22PM +0100, Andy Armstrong wrote:
> On 18 Aug 2008, at 18:18, Eric Wilhelm wrote:
> >> I think that in this case we're probably seeing something like the
> >> scheduler being O(N^2) and there being a large number of tests.
> >
> > Oh right.  I should have looked at Nick's profiler output more
> > carefully.
> >
> > So, why is scheduling so complicated?  O(N^2) implies that scheduling
> > the next test requires us to run through the list of already completed
> > tests!
> 
> 
> It's probably not quite N^2 but I bet it doesn't scale particularly  
> well. It's like that for no better reason than that I figured I'd get  
> it working and then discover whether it was fast enough. Evidently it  
> isn't :)

That's not entirely accurate. It is fast *enough*, because running tests in
parallel takes less wall clock than running them serially. (And I like this)

But what it isn't is "as fast as it easily could be". Well, at least, I think
that it's not.

> I'll take a look at it this week. Thanks for the investigation by the  
> way Nicholas.

Cool. Thanks. I sort of got digressed into working out the test coverage of
T::H and then finding that Devel::Cover doesn't (or at least) didn't pass one
test on blead. (Which Paul is aware of, can replicated, and knows is due to
change 33710 in blead which fixed the line numbers in elsif)

Nicholas Clark