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>...