Wayne Simmons wrote:
>> Bill Luebkert said:
>> It would help if you gave an example of what you're trying to accomplish.
>> I've used those vars maybe once or twice in testing, but never found a
>> need for them in any of my normal scripts (but then again, I bleieve number
>> vars ($1, $2, ...) have the same cost which I do use frequently).
>>
>> It's a one-time penalty and I wouldn't really worry much about it. You
>> could time it and see what the penalty actually is and see if it's
>> warranted.
>
> Bill,
>
> According to sawampersand.pm :
>
> There's a global variable in the perl source, called PL_sawampersand.
> It gets set to true in that moment in which the parser sees one of $`,
> $', and $&. It never can be set to false again. Trying to set it to
> false breaks the handling of the $`, $&, and $' completely.
>
> If the global variable C<PL_sawampersand> is set to true, all
> subsequent RE operations will be accompanied by massive in-memory
> copying, because there is nobody in the perl source who could predict,
> B<when> the (necessary) copy for the ampersand family will be needed.
> So B<all> subsequent REs are considerable slower than necessary.
>
> End quote
>
> So the "bad variables" I'm concerned about are not the same as the $1, $2
> variables, nor is it a "one time hit" as you indicate.
I was using the man pages for my source - which looking at them a second time
are not all that explicit.
perlre man page:
WARNING: Once Perl sees that you need one of $&, $`, or $' anywhere in the
program, it has to provide them for every pattern match. This may
substantially slow your program. Perl uses the same mechanism to produce
$1,
$2, etc, so you also pay a price for each pattern that contains capturing
parentheses. (To avoid this cost while retaining the grouping behaviour,
use
the extended regular expression "(?: ... )" instead.) But if you never use
$&, $` or $', then patterns *without* capturing parentheses will not be
penalized. So avoid $&, $', and $` if you can, but if you can't (and some
algorithms really appreciate them), once you've used them once, use them at
will, because you've already paid the price. As of 5.005, $& is not so
costly as the other two.
The second last sentence kinda contradicts the first sentence, so without some
testing, I'm not sure what the full speed implications would be. As far as I'm
concerned, I will always be using ()s and number variables at will until I run
into a situation where it appears they are degrading my code excessively.
As far as your code below:
perlvar man page:
$` is the same as "substr($var, 0, $-[0])"
$& is the same as "substr($var, $-[0], $+[0] - $-[0])"
$' is the same as "substr($var, $+[0])"
$1 is the same as "substr($var, $-[1], $+[1] - $-[1])"
$2 is the same as "substr($var, $-[2], $+[2] - $-[2])"
$3 is the same as "substr($var, $-[3], $+[3] - $-[3])"
> What I'm doing is detecting if a marker exists in a string then truncating
> it at the marker point ie:
>
> if ($buffer =~ /MARKER/)
> {
> $buffer = $&
> #OR something like:
> #$buffer = substr($buffer,0,$-[0]);
> #OR even:
> #$markerpos = index($buffer,MARKER);
> #$buffer = substr($buffer,0,$markerpos);
> }
>
> It's just an efficiency question that I suppose is not critical in my
> program but I always like to write efficient, maintainable code. Also I'm
> still in the implementation phase, and can't really do timed tests until
> later, so I was hoping a Guru (like yourself, or someone from activestate)
> would have some personal knowledge on the matter.
I almost always tend to use:
$buffer =~ s/^(.*?)MARKER.*$/$1/;
or
$buffer =~ /^(.*?)MARKER/;
$buffer = $1;
I'm not sure without some bench test what sort of penalty this might entail
over other methods, but 99% of the time it's not relevant.
_______________________________________________
ActivePerl mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
