Robert Brown wrote:
> Casey West writes:
> 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.
I think I see the question more clearly here. Actually, I would say that you
are better off using Perl built-ins, particularly in the case of sorts and
similar problems. What you want to bear in mind is that Perl is written
largely in C, and the builders make very good use of the optimizations
available in that language in implementing the built-in functions. The Perl
sort is lightning fast. Regex solutions are as fast as problems of their
level of complexity can be implemented. If that sounds vague, it's because
the Perl regex is so well optimized. Say you do a regex that asks only for
the right string at the base: if ($string =~ /^Target/). The Perl regex will
do only enough work to evaluate the question posed in the regex. On the other
and, if you do
my $string =~ /Total (\d[12dg5]{2,5})+\"(.*)\"/g;
you might expect a somewhat heavier processing load. Of course, if
information structured with such parameters is your pot of gold, it may be
worth the expense, because it will extract it [probably--I didn't test the
second regex].
Clearly, the more complicated your regex is in its structure, the more
processing will be involved in using it. This is why, for instance, list
members often caution against trimming a string in a single statement.
$string =~ s/^\s+(.*)\s+$/$1/;
is much more costly than:
$string =~ s/^\s+//;
$string =~ /\s+$//;
When used consciously, with at least a general awareness of the processing
load being invoked, regexes can do some really incredible things.
The problem with rolling your own in Perl is the overhead of Perl's magic
variables. Although Perl scalars have very useful features, each scalar does
require structures to support them. So when you try to compete with built-in
functionality, operating at full, optimized C-language implementation speed,
you are carrying a lot of baggage into the race. You will probably lose, no
matter how efficient your code.
Perl actually does call for a different coding approach than C. Would any C
coder try to roll their own stdio? It seems like that would be a pretty rare
occurence. the standard library is part of the language, and C-coders make
use of it. The core and standard modules are likewise a part of the Perl
language as a whole.
It can't hurt to do some experimenting on your own, and to compare
performance. Just keep an open mind about it. Since it sound like you have
a considerable investment in your C work, you might also consider packaging
some of it for use in Perl. I'm not recommending embedded code here, so much
as looking for Perl interfaces to compiiled C object files that your Perl
programs can call on for specialized and highly optimized jobs. Except to
point you in that general direction, I can't offer much help. I think there
are others on the list, though, who can point you to more depth material on
integration.
Joseph
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
