Re: shell vs. filehandler

Isn't this what the read command was designed for?

open($handle, $fpath);
read($handle, $str, $maxsize);
close($handle);
[download]

The advantage of this method is you're specifying the maximum size of the data in advance, so memory can be allocated all at once and reading isn't in chunks. I prefer this for files small enough to comfortably fit into available memory.

Comment on Re: shell vs. filehandler Download Code

Replies are listed 'Best First'.
Re^2: shell vs. filehandler by halley (Prior) on Feb 11, 2005 at 14:39 UTC
(1) premature optimization (2) no error exception handling (3) uses a magic constant which may require maintenance (4) not immediately clear to an idiomatic perl programmer In more depth, (1) Don't try really hard to think about the time overhead of memory allocation in one step or many. That's the computer's job. Your job is to write an effective algorithm. If the FINISHED program runs too slowly, THEN figure out why. (2) When you use system calls, like `open()` and `read()`, then you should also check their returned values for any unexpected error conditions. When you use the high-level equivalents like `<ARGV>`, this is done for you in a generic, consistent way (die). (3) When I'm designing code, I am at the beginning of the lifetime of the application. Any hardcoded "maximum size" constants are based on my best guess at the time, but somebody else might need to increase the complexity of that config file, or add more words to the dictionary, or any other mission creep. Someone's going to have to go in and find out why the application can't check the spelling of any words starting with Z. Someone's going to have to modify (and re-distribute) the application. There's a reason Perl doesn't require explicit string and array length allocations. Length should not be your concern. (4) I use the `read()` function so seldom that I would have to look it up to see what the "maxsize" argument was, and then come to trust that if the file was shorter than this maximum, that it would indeed get read in its entirety. I already know that the slurp idiom works every time. I didn't count off for `use strict` compliance, but remember to identify or declare all those lexicals accurately. -- `[ e d @ h a l l e y . c c ]`	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: shell vs. filehandler
by halley (Prior) on Feb 11, 2005 at 14:39 UTC

In more depth,

(1) Don't try really hard to think about the time overhead of memory allocation in one step or many. That's the computer's job. Your job is to write an effective algorithm. If the FINISHED program runs too slowly, THEN figure out why.

(2) When you use system calls, like open() and read(), then you should also check their returned values for any unexpected error conditions. When you use the high-level equivalents like <ARGV>, this is done for you in a generic, consistent way (die).

(3) When I'm designing code, I am at the beginning of the lifetime of the application. Any hardcoded "maximum size" constants are based on my best guess at the time, but somebody else might need to increase the complexity of that config file, or add more words to the dictionary, or any other mission creep. Someone's going to have to go in and find out why the application can't check the spelling of any words starting with Z. Someone's going to have to modify (and re-distribute) the application. There's a reason Perl doesn't require explicit string and array length allocations. Length should not be your concern.

(4) I use the read() function so seldom that I would have to look it up to see what the "maxsize" argument was, and then come to trust that if the file was shorter than this maximum, that it would indeed get read in its entirety. I already know that the slurp idiom works every time.

I didn't count off for use strict compliance, but remember to identify or declare all those lexicals accurately.

--
[ e d @ h a l l e y . c c ]

[reply]
[d/l]
[select]