Paul Beckingham wrote:
>> I'm with Adrian. Printing out "ok" 100,000 times shouldn't be a
>> big deal unless you're reading the TAP via some sort of IP over
>> clay tablets protocol. But...
>
> My test estimate is two orders of magnitude larger, so it actually is a
> big deal to capture and store those results.
This raises the question, why are you storing the raw results rather than
storing the results after having been run through a TAP parser?
> But I would like to point out that there is a very low information
> density in 100,000 "ok" messages. I was looking to see what folks
> thought of an *optional* feature that doesn't bother outputting the "ok"
> messages, just the interesting ones. Hence the "sparse".
Its important to know that a test ran.
Essentially, I'm unconvinced that this is A) a real performance problem,
running 10 million tests should swamp parsing 10 million TAP lines and B) can't
be solved with a more flexible TAP parser than Test::Harness such as Ovid's
TAPx::Parser. TAPx::Parser can be used to strip out all the ok lines, then you
store what's left.
One of the benefits of having a decent protocol is that you don't have to keep
changing the protocol to do interesting things. The parser can do the
interesting things. And we finally have an interesting parser in TAPx::Parser.
Here ya go.
#!/usr/bin/perl -w
use strict;
use TAPx::Parser;
my $parser = TAPx::Parser->new( { source => $ARGV[0] } );
while( my $result = $parser->next ) {
print $result->as_string, "\n" if !$result->is_test or !$result->is_ok;
}
It does add significant overhead. Here's the example of one of
Regexp::Common's tests.
0 windhund /private/var/local/cpan_shell/build/Regexp-Common-2.120$ time perl
-Ilib ~/tmp/strip_ok t/number/integer.t
1..23534
real 0m4.882s
user 0m5.469s
sys 0m0.155s
0 windhund /private/var/local/cpan_shell/build/Regexp-Common-2.120$ time perl
-Ilib t/number/integer.t > /dev/null
real 0m2.051s
user 0m2.020s
sys 0m0.018s
TAPx::Parser has not yet been optimized so some profiling information would
likely prove interesting. I would much rather improve the parser than change
the protocol.
