Casey West writes: > : "Does the regular expression mechanism in perl optimize regular > : expressions such as the one you used earlier in this thread so that > : the execution overhead is nearly as good as the C approach I outlined > : earlier in this thread? In other words, for the problem stated > : earlier, does o(C) = o(perl)? > > The answer is, C almost always going to be much faster almost all the > time, YMMV. Really the only way to tell is with tests and benchmarks, > but you can almost always bet on C.
Sorry again for my confusing way of expressing myself. Although I wrote my example in C, that was because I am a novice perl programmer, but an experienced C programmer, so I expressed my algorithm in C. The idea was to compare the execution effeciency of a perl regular expression approach to a less syntacticly compact algorithmic approach using loops and conditionals, still written in perl, to edit the string. I just used C so you all would not beat me up over perl syntax details instead of answering the real question. Is perl going to be comparably efficient whichever way you code it, or is the explicit test and loop approach usually going to be faster for simple jobs? I want to know when to use the regex approach and when not to. Yes, I realize that much of the time it is not computer time one needs to optimize for, but programmer time, especially for "throw-away" hacks that only take miliseconds to run anyway. For the big jobs, one must be more careful. For example, right now I am working on a set of scripts to implement a production backup server. A live test run mucks around with about 100 GB of files over a network that I wish was faster, stuffing those files safely into a "negative time" image on a RAID5 array, and takes about 6 hours to run. It is a good idea to try to make such long jobs run quicker! -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
