Parallel thoughts

[Andy Armstrong]

On 1 Oct 2007, at 22:41, Andy Armstrong wrote:
> So we could do something like this:
>
> * The default is single process
>
> * There's a safe parallel option which is handy for I/O bounds tests
>
> * There's a speedy forking option which doesn't capture test output
> line by line - but it still
>    gets the summaries right (and correctly lists which test numbers
> failed) and it scales well to
>    any number of cores.

r657 is approximately the above. It adds a --fork option to prove  
which selects a forking, no output of individual tests behaviour.  
Some random data for Regexp::Common (which probably isn't typical of  
anything):

$ prove -rbQ
All tests successful.
Files=56, Tests=222860, 28 wallclock secs (19.98 usr  1.46 sys +  
18.94 cusr  0.77 csys = 41.15 CPU)
Result: PASS
$ prove -rbQ -j 9
All tests successful.
Files=56, Tests=223059, 33 wallclock secs (27.09 usr  1.82 sys +  
18.89 cusr  0.71 csys = 48.51 CPU)
Result: PASS
$ prove -rbQ -j 9 --fork
All tests successful.
Files=56, Tests=222840, 22 wallclock secs ( 0.19 usr  0.07 sys +  
39.24 cusr  2.21 csys = 41.71 CPU)
Result: PASS
$ prove -rbQ -j 4 --fork
All tests successful.
Files=56, Tests=223118, 21 wallclock secs ( 0.19 usr  0.05 sys +  
39.01 cusr  2.12 csys = 41.37 CPU)
Result: PASS

I don't intend the dependency on Parallel::Iterator to remain -  
that's just an easy way to get the forking behaviour so we can play  
around with it.

I'd be interested to see what sort of comparisons people get on  
different hardware with different flavours of test.

-- 
Andy Armstrong, Hexten