lvalue substr has to construct a magic scalar and then pipe the assignment to that scalar over to the original string and then destroy the magic scalar. Of course that takes longer than just adjusting a few fields in the original string's SV struct.
If you don't like only being able to use lvalue substr 1.4 million times per second, then just use 4-argument substr instead. Yes, somebody could spend a bunch of time trying to hack in an optimization such that if lvalue substr is used in the simplest way, code that is written like substr($str,$off,$len)= $sub; actually gets compiled like substr($str,$off,$len,$sub); (update: note the semicolon, ikegami). But, given that the resources for such work are clearly finite (and you seem unable to be such a resource and I've become unwilling), I almost find it hard to think of something I'd put as a lower priority than such a hack.
Having a simple, efficient way of changing substrings (4-arg substr) and also having a more-complicated-to-implement and slightly (2-fold) slower alternative that allows more complex use cases (substr($str,$off,$len) =~ s/.../.../g;) is a lovely feature, not something even close to being a bug.
- tye
In reply to Re: Bug or WAD in lvalue substr? (against)
by tye
in thread Bug or WAD in lvalue substr? (again.)
by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |