On 6/9/05, Wiggins d'Anconia <[EMAIL PROTECTED]> wrote: > 4. Speed/Forking: because backticks causes a fork, you are using system > resources in a way you wouldn't necessarily need to if you were able to > use a built-in function. When Perl forks, it forks an exact copy of the > running process and then transitions to the new command (at least on > *nix systems) which may cause use of memory resources, file descriptors > (which include open sockets to databases or possible remote locations), > and other system level attributes that you wouldn't otherwise need. And > the memory footprint of the running process includes all loaded modules > so could be quite large. When running a forked system command, the perl > interpreter has to fork, then exec the shell, the shell then has to > parse the command line (which unless you have seen the parsing map you > wouldn't believe how long this takes), then it has to fork and exec > again into the running process, that process may then have to do its own > option parsing, etc. which all could have been avoided by using the > internal method. So it is almost always slower to call a system command > when an internal method is available. Finally each call to > system/backticks is independent, meaning that depending on the command > being run and the optimizations of the alternatives there is no > potential to use caching, session management, etc. to improve > efficiency. Although system/backticks are written correctly in Perl 5, > if you are using your own fork/exec model and don't include sufficient > 'wait' code then your system may also become swamped by zombies, > eventually causing a locked system, assuming you don't hit the memory > limit first.
You (well, I) learn something new every day. That's kind of funny, actually, (to me) that backticks load all the modules in use again just to run hostname. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
