http://www.perlmonks.org?node_id=7662


in reply to Re: How To Do This Better?
in thread How To Do This Better?

You probably meant to say:
while(!eof(FILE)) { my $c = getc(FILE); $count{lc($c)}++ if $c=~/[a-zA-Z]/; }
As your original seems to give up at the first newline. Plus, you have to remember that perl compiles regular expressions to make them run faster, particularily when they don't require backtracking (basically creates a finite state machine to do the job). As these are executed in C, writing perl to do the same job is *always* going to be slower.

Plus getc() isn't exactly a star performer, either. Maybe use the unbuffered IO stuff if you want to improve performance in this area, though you'd really have to be after squeezing the last ounce of speed out of the thing in that case (and you'd have to remember not ever to use any of the buffered routines)

The important thing is to try it, of course, especially where perl performance is concerned. Remember that perl is interpreted (it compiles to a byte-code at runtime), but the internal functions are compiled, and are always faster.

perl /home/ahunter/grob.pl < xlib.ps 39.04s user 0.24s system 95% cpu 41.126 total

Well, a 3x speed-up over the original isn't really all that bad, I suppose.

-- Andrew

Replies are listed 'Best First'.
RE: RE: Re: How To Do This Better?
by NoTwoGroo (Initiate) on Apr 15, 2000 at 01:12 UTC
    Well, unless getc() works differently on non-unix systems (and it wouldn't surprise me), it's documented to read until EOF, so the while(not(eof(X))) doesn't seem necessary. getc() doesn't care about newlines.
    Even given the possible less-than-best read performance of getc() relative to <FILE>, I'd still expect the getc loop to be faster, since even though regexps are fast, not having to use them at all is faster still. Doing a split or a s/// on each line of input is likely to kill your speed gain.
    Of course, there are trade offs... if all your files are small, you probably don't care if you have the fastest three lines. For anything other than looking at each character in the file, using getc() probably will suck. But if it's applicable, benchmark whatever alternatives you're looking at... On my box, a getc() loop was significanly faster than <FILE>...