Subject: | cut Test::Parser memory usage by 90% |
Date: | Tue, 30 Apr 2013 10:47:51 +0100 |
To: | bug-test-harness [...] rt.cpan.org |
From: | Nicholas Clark <nick [...] ccl4.org> |
TAP::Parser can use a lot of memory store the test results. A test run for
blead needs 134M. Changing the storage representation for the common case
(all tests pass) cuts this by over 90%. (The first patch)
It, surprisingly, also reduces the run-time measurably, at least for
larger test suites. Running blead's tests 9 ways on a modern 8 core machine
it drops the runtime from 146s to 134s:
Results from running dumbbench ./perl harness
Before: cmd: Rounded run time per iteration: 1.4594e+02 +/- 3.8e-01 (0.3%)
After: cmd: Rounded run time per iteration: 1.3387e+02 +/- 3.6e-01 (0.3%)
I'm assuming that this is because it reduces pressure on the CPU L1 and L2
caches. It is consistent with what I remember finding when experimenting
with parallel tests back in 2007 on the loaned Sun T1 - throughput maxed out
at around 9 parallel streams, because more than that and the test aggregator
process was maxing out its CPU, causing all the running tests to have to wait
for it.
The second patch reduces the memory usage a bit further, by forcing the test
number to be stored as a number, not a string. It also drops the wallclock
runtime a little bit more
cmd: Rounded run time per iteration: 1.3281e+02 +/- 3.3e-01 (0.2%)
but I'm not so sure whether it's worth it, as it's a "reasonable" amount
of complication.
grep.cpan.me suggests that nothing is actually subclassing either
TAP::Parser or TAP::Parser::Gramar, so nothing should notice these changes.
(There isn't even well behaved code using the accessors, let alone naughty
code poking inside)
I've tested these out as smoke-me/nicholas/TAP-Parser-diet and they aren't
causing problems.
Nicholas Clark
Message body is not shown because sender requested not to inline it.
Message body is not shown because sender requested not to inline it.