Dave Gray wrote: > 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. >
Ah, but that is actually the good part, it doesn't re-load the modules (at least on most modern *nix systems). Meaning it doesn't have to reparse, etc. it actually does a direct memory copy which makes fork/exec very fast when you want to do something similar, the problem only happens when you have a large process that forks to a small one and you run into memory consumption issues. And this may or may not be the case for the system/backtick internals, but it is for normal Perl forks so I assumed that it was for those as well, one of the internals gurus can confirm or not. This was actually something that was very beneficial when I was developing an app using POE that forked off processes to run concurrently. It meant we didn't have to reload some fairly heavy modules (POE, Log4perl, Mail::Box, etc.) which made the forking fast. This is a good reason why you shouldn't shell out to another Perl interpreter specifically, which is why the system was reengineered. It was reengineered from a set of 6 independent script calls which each had to load modules independently each time, to a single Perl head that forked each of the 6 steps, meaning the modules were loaded once when the daemon was run, saving a ton of loading time over the life of the process. But the overhead for a forked/shelled process is either a lot or a *really* lot depending on how it functions and how optimized the underlying OS is for forking processes. http://danconia.org -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
