in reply to How To Do This Better?

If you're pulling your input from a file, then
while(my $c = getc(FILE)) { $count{lc($c)}++ if $c=~/[a-zA-Z]/; }
is going to be quite a bit faster than anything involving split() or a regexp.

getc() has some issues, but this seems like an ideal use for it.

Replies are listed 'Best First'.
RE: Re: How To Do This Better?
by ahunter (Monk) on Apr 15, 2000 at 00:14 UTC
    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
      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>...