Re: [SPOILER] Solution to Perl 'Expert' Quiz-of-the-Week #22

"Randy W. Sims" <[email protected]>
Newsgroups gmane.comp.lang.perl.qotw.discuss
Message-ID <[email protected]>
On 8/30/2004 12:42 PM, Xavier Noria wrote:
> On Aug 30, 2004, at 18:26, Randy W. Sims wrote:
> 
>> The original was run on Windows 2000 w/ perl 5.6.1. Similar 
>> processors, but run times are very different. I suspect the difference 
>> must be due to file caching. From observing the run on linux, it 
>> /seems/ like the entire word file is remaining in the file cache, 
>> where on Windows it reread the file each time. That's my best guess at 
>> what's going on, but it is just a guess.
> 
> 
> Interesting, what is that file cache? Does it have to do with the 
> operating system? Is its usage observable somehow?

A file cache stores file data in RAM to help improve performance in IO
operations. If the data is sometimes fetched from the disk and sometimes
from RAM it can taint the benchmark. Process scheduling is another thing
to worry about in benchmarking: I usually increase the priority of the
benchmarking process and close most other tasks. Low memory can also
cause problems: swapping, thrashing, etc.

I'm not sure what actually cause the strange figures I got. (I'm kinda
embarassed that I wasn't more suspicious of those numbers.) I tried a
few things but, still get the same numbers. Running it with a 5.8.x perl
gives more consistent results, so maybe it is something with Benchmark
on 5.6?

Anyway, I think the (correct) results do show enough of a speed
difference to justify avoiding the use of any combinations of two or
more of C<map>, C<grep> and C<< <> >> for any large data sets.

Randy.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.