Profiling parallel tests

[Eric Wilhelm]

# from chromatic
# on Sunday 17 August 2008 14:57:

>>However, I keep noticing that the parallel harness itself is
>>accounting for quite a lot of CPU time. 
>> ...
>> Presumably the elegant functional programming/recursive approach is
>> hurting performance here?
>
>There's little "presumably" about it.  The HOP-style parsing is indeed
>elegant, but a good Scheme or Lisp implementation behaves very
> differently from Perl 5's implementation.

There is also a fair bit of cost in providing flexibility, which goes 
unused for the majority of setups.

My reading suggests that before parsing starts (often at constructor 
time or earlier), the unused hooks and callbacks are known to be 
unused -- which means that some fairly extensive restructuring could 
turn the optimization into a rather straightforward class composition 
problem.  But I don't see that being any small task and IIRC a lot of 
the structure of the harness/parser is heavily entrenched in the test 
suite.

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.

--Eric
-- 
Atavism  n:  The recurrence of any peculiarity or disease of an ancestor
in a subsequent generation, usually due to genetic recombination.
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------