I'm curious what sort of trials lead you to say that using sysread "feels slow"... How slow does it "feel" compared to the default i/o methods? (How much do your colleagues notice your presence when you use sysread, as opposed to the default methods?)

Since almut has already pointed out how to build perl 5.10 with your own custom input buffer size, that's likely to be the way to go -- a specific build of perl for this specific app...

But I'd still be tempted to try a little more with the sysread approach (esp. since you seem to have made some progress with it already), and as for missing PerlIO's utf8 layer, well, you do still have Encode, which basically does the same thing.

And I think it's worthwhile to consider starbolin's comment about improving the use of local disk in your optimization strategy -- in addition to anything else you do. Whatever solution you pick should probably include making a one-time copy of big data chunks to local disk, if only to keep your process from stalling everyone else on the network.

(If the process happens to be modifying or rewriting file contents, all the more reason, perhaps, to work on local storage until the process is done, then "upload" the finished product to your network drives. NFS writes are more expensive than NFS reads, so the less you do NFS writes, the better.)

update: To follow up on my remark about Encode, this snippet produces no warnings about "wide character data", and outputs the appropriate 3-byte sequence (two-byte utf8 sequence for á followed by LF):

perl -MEncode -e '$_=encode("utf8","\x{e1}\n"); syswrite(STDOUT,$_)'
[download]

Doing the same thing on input involves passing your input string as the 2nd arg to decode("utf8",...) -- the return value is a perl utf8 string.