Text parsing and substitution

[Guest]

: >: ><quote>
: >: > Due to an unfortunate accident of Perl's implementation, "use English"
: >: > imposes a considerable performance penalty on all regular expression
: >: > matches in a program, regardless of whether they occur in the scope of
: >: > "use English".
: >: ></quote>
: >
: >: That _is_ misleading... until it leads to:
: >
: > copy of perlvar (Perl 5.8.6) ends the annotation on bugs with the phrase:
: >
: ><quote>
: > See the Devel::SawAmpersand module documentation
: ></quote>
: >

: Then I think you can probably guess where I quoted it from, eh?

Certainly so.

In the meantime, I wrote a few little scripts demonstrating the effects
of a single $& anywhere in the code and its detrimental impact on other
regexes. I'll post it later.

: Anyway, _I_ think the issue deserves the "good treatment" in the
: std docs rather than by reference to something else that you have
: to go get...

I think so, too. Found the situation in perlvar.pod slightly annoying.

Oliver.

 

[Donald King]

In the meantime, I wrote a few little scripts demonstrating the effects
of a single $& anywhere in the code and its detrimental impact on other
regexes. I'll post it later.
[snip]

Oliver.

Wandering rather OT, but is there a particular reason why $& still has
an interpreter-wide performance hit in Perl 5.8? Now that @+ and @-
exist, couldn't $& just compute substr($var, $-[0], $+[0] - $-[0]) at
runtime, like a tied variable?

 

[Ben Morrow]

In the meantime, I wrote a few little scripts demonstrating the effects
of a single $& anywhere in the code and its detrimental impact on other
regexes. I'll post it later.
[snip]

Oliver.

Wandering rather OT, but is there a particular reason why $& still has
an interpreter-wide performance hit in Perl 5.8? Now that @+ and @-
exist, couldn't $& just compute substr($var, $-[0], $+[0] - $-[0]) at
runtime, like a tied variable?

Not if $var has changed in the interim. Saving the old value is what
causes the hit.

Ben

 

[Donald King]

In the meantime, I wrote a few little scripts demonstrating the effects
of a single $& anywhere in the code and its detrimental impact on other
regexes. I'll post it later.
[snip]
Oliver.

Wandering rather OT, but is there a particular reason why $& still has
an interpreter-wide performance hit in Perl 5.8? Now that @+ and @-
exist, couldn't $& just compute substr($var, $-[0], $+[0] - $-[0]) at
runtime, like a tied variable?

Not if $var has changed in the interim. Saving the old value is what
causes the hit.

Ben

Ah, didn't think about $var changing after the match.