My general recollection of /p and similar, is that there have been several
attempts over the decades to fix (or at least ameliorate) the $& bug -
i.e. that when $', $& or $' appear anywhere within a program (e.g. in a
use'd module) at least once, the performance of every regex in the program
takes a hit, because the match now has to save a copy of the whole string
just in case $& or similar gets used.
As well as the performance issue, there was also the bug of
/xyz/; eval '$&'
where even though the xyz match doesn't save a copy of the string, it is
still later used.
Some of the attempts over the years IIRC are:
- /p and ${^MATCH} etc
- noting the presence of $`, $& and $' individually and only copying
the parts of the string that are needed. Or in other works, make
PL_sawampersand a 3-bit value rather than a boolean. (That was my
work).
- COW.
My vague recollection is that when COW was introduced, it was seen as the
ultimate fix for the $& issue, and some of the other mechanisms were
disabled as no longer needed. But this was overly optimistic - not all
strings to be matched are COW.
I think there was also an issue with s///; because the string was about to
get modified, it got immediately unCOWed, and so $& became an issue again.
Sometimes things became pathologically bad, especially with large
buffers.
In summary: I think this is a complex issue, and should be examined and
fixed carefully and holistically; we certainly shouldn't start just
tweaking /p or whatever on its own, and certainly not late in the
development cycle. And any fixing of docs should be done in a way which
doesn't hold us hostage to fortune.
