On Jun 21, 2005, at 5:59 PM, Geoffrey Young wrote:
This seems unfortunate for at least two reasons:
1) it ends up taking a really long time to run the tests. At some
point, maybe long enough that nightly tests become prohibitive (even
more so for continuous integration).
We have a substa
>>> This seems unfortunate for at least two reasons:
>>> 1) it ends up taking a really long time to run the tests. At some
>>> point, maybe long enough that nightly tests become prohibitive (even
>>> more so for continuous integration).
> We have a substantial Perl code base (as I've said sever
On Jun 21, 2005, at 1:09 PM, James E Keenan wrote:
Kevin Scaldeferri wrote:
It seems to me like the time Devel::Cover takes to do its
book-keeping when a process terminates is linear in the total number
of files in the cover_db, rather than linear in the number of files
involved in that part
Kevin Scaldeferri wrote:
It seems to me like the time Devel::Cover takes to do its book-keeping
when a process terminates is linear in the total number of files in the
cover_db, rather than linear in the number of files involved in that
particular process.
[snip]
This seems unfortunate for a
On Jun 14, 2005, at 1:32 PM, Kevin Scaldeferri wrote:
A little more interesting information. I ran a coverage test for the
full code base. Then I did this:
[kevin]% time perl -MDevel::Cover -e 1
...
perl -MDevel::Cover -e 1 14.19s user 0.88s system 79% cpu 18.997 total
After spending a
A little more interesting information. I ran a coverage test for the
full code base. Then I did this:
[kevin]% time perl -MDevel::Cover -e 1
...
perl -MDevel::Cover -e 1 14.19s user 0.88s system 79% cpu 18.997 total
Again, perhaps there is something about Devel::Cover or about Perl that
pre
It seems to me like the time Devel::Cover takes to do its book-keeping
when a process terminates is linear in the total number of files in the
cover_db, rather than linear in the number of files involved in that
particular process.
This means that as your code base grows, the time to run unit
