Profiling parallel tests

[Nicholas Clark]

On Mon, Aug 18, 2008 at 03:19:47PM +0100, Andy Armstrong wrote:
> On 17 Aug 2008, at 23:59, Eric Wilhelm wrote:
> > In general, the speed problem is most prominent when a large number of
> > subtests ("ok ...") are printed without much computation being done by
> > the test process.  There was some benchmarking and discussion in the
> > archives and commits one year ago if anyone cares to pursue it.
> 
> 
> 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.

Isn't it this part:

http://www.wu-wien.ac.at/usr/ma/nclark/blead_harness_34207_r1162/..-lib-TAP-Parser-Scheduler.pm-line.html#220

sub get_job {
    my $self = shift;
    my @jobs = $self->_find_next_job( $self->{schedule} );
    return $jobs[0] if @jobs;

    # TODO: This isn't very efficient...
    return TAP::Parser::Scheduler::Spinner->new
      if $self->get_all;

    return;
}


The results of that call to get_all() aren't used. It seems that it could be
replaced by a get_any(), (Well, not_finished()) method, that returned true
as long as there were any tests still to run, which I assume is a test that
can be short-circuited.

Nicholas Clark