Front page | perl.perl5.porters |
Postings from January 2001
> > That is true, the timing of the whole suite is to be taken with a
> > biiig grain of salt -- but a test of consisting of, say, 1 second of
> > actual test (CPU time being burned) and 1 second of sleep gets sped up
> > by, say, 10%, it means that the CPU time really got slashed by 20%,
> > which is actually *more* significant than without the sleep.
>
> But in
>
> u=1.33 s=0.46 cu=62.27 cs=10.54 scripts=273 tests=21120
>
> real 2m16.388s
> user 1m3.610s
> sys 0m11.000s
>
>
> (which is from time ./perl TEST)
>
> I was under the impression that real is wallclock, and the other two
> are user and system call CPU time, not elapsed time.
Correct. I was in the above talking more about the timings for one
test, not the whole suite.
> > I think the most dubious element of the test suite as a whole is the
> > large number of separate and relatively small scripts, the operating
> > system (and filesystem, and networking, and ...) dependent startup
> > time may taint the results quite a lot.
>
> Lots of lovely perl symbols, all being put into symbol tables lots of
> times, all being hashed each time?
Very possible. But how about them op/numconvert and op/int failures, eh? :-)
> If so, that might explain it unfairly favouring faster hash algorithms
>
> Nicholas Clark
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Thread Previous
|
Thread Next