In the thread at Ways to delete start of string, one of the most notable things to come out of it in my eyes, is the large discrepancy in performance of substr used as an lvalue and the 4-arg substr variant. Using a modified form of the benchmarks presented there these are typical result sets:

Update: Replaced the timing with those from a better benchmark that isolates the code under test from the costs of allocating destructable test data. The effect is to highlight the inadaquacy of the earlier benchmark attempts, most notable by the fact that the reverse-chop-reverse method is now shown to be the slowest (as one would intuatively expect.

These changes do not affect the meat of this meditation, as the lvalue results are still far slower than the 4-arg results.

[14:28:20.34] c:\test>\Perl510\bin\perl5.10.0.exe 688308.pl -loops=1e2
              Rate     reverse substr_copy       subst substr_lval  su
+bstr_mod
reverse     5.79/s          --        -78%        -96%        -97%    
+    -98%
substr_copy 26.0/s        349%          --        -84%        -85%    
+    -92%
subst        162/s       2692%        522%          --         -5%    
+    -48%
substr_lval  170/s       2837%        554%          5%          --    
+    -45%
substr_mod   310/s       5257%       1094%         92%         82%    
+      --

[14:29:08.20] c:\test>\Perl510\bin\perl5.10.0.exe 688308.pl -loops=1e3
              Rate     reverse substr_copy       subst substr_lval  su
+bstr_mod
reverse     5.91/s          --        -77%        -97%        -97%    
+    -98%
substr_copy 26.1/s        342%          --        -85%        -85%    
+    -92%
subst        169/s       2767%        548%          --         -2%    
+    -47%
substr_lval  173/s       2832%        563%          2%          --    
+    -45%
substr_mod   317/s       5264%       1113%         87%         83%    
+      --

[14:29:44.37] c:\test>\Perl510\bin\perl5.10.0.exe 688308.pl -loops=1e4
              Rate     reverse substr_copy       subst substr_lval  su
+bstr_mod
reverse     5.85/s          --        -78%        -96%        -97%    
+    -98%
substr_copy 26.2/s        349%          --        -84%        -85%    
+    -92%
subst        167/s       2750%        535%          --         -5%    
+    -48%
substr_lval  176/s       2908%        570%          6%          --    
+    -45%
substr_mod   321/s       5383%       1121%         92%         82%    
+      --

[14:30:21.73] c:\test>\Perl510\bin\perl5.10.0.exe 688308.pl -loops=1e5
              Rate     reverse substr_copy       subst substr_lval  su
+bstr_mod
reverse     5.85/s          --        -78%        -97%        -97%    
+    -98%
substr_copy 26.3/s        350%          --        -84%        -85%    
+    -91%
subst        168/s       2767%        536%          --         -3%    
+    -46%
substr_lval  173/s       2862%        558%          3%          --    
+    -44%
substr_mod   309/s       5191%       1075%         85%         79%    
+      --
[download]

Whether my benchmark is any more or less accurate than others is irrelevant to this issue, as it is the consistent placing of lvalue-substr as slowest and 4-arg substr quickest, when what they are doing should be exactly the same. The results (with a minor discrepancy that I've raised as a bug in the past, but had dismissed), is the same:

>\Perl510\bin\perl5.10.0.exe -MDevel::Peek -wle"
    $x = 'fred'; Dump( $x ); 
    print substr( $x, 0, 1 )=''; Dump( $x )"

SV = PV(0x226f64) at 0x182a19c
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x18305ec "fred"\0
  CUR = 4
  LEN = 8

SV = PVIV(0x228f40) at 0x182a19c
  REFCNT = 2
  FLAGS = (POK,OOK,pPOK)
  IV = 1  (OFFSET)
  PV = 0x18305ed ( "f" . ) "red"\0
  CUR = 3
  LEN = 7

>\Perl510\bin\perl5.10.0.exe -MDevel::Peek -wle" 
    $x = 'fred'; Dump( $x ); 
    print substr( $x, 0, 1, ''); Dump( $x )"

SV = PV(0x226f64) at 0x182a19c
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x18305ec "fred"\0
  CUR = 4
  LEN = 8
f
SV = PVIV(0x228f40) at 0x182a19c
  REFCNT = 1
  FLAGS = (POK,OOK,pPOK)
  IV = 1  (OFFSET)
  PV = 0x18305ed ( "f" . ) "red"\0
  CUR = 3
  LEN = 7
[download]

The sharp-eyed among you will notice the effect of the 'bug' I mentioned above, in that the residual result of the two expressions (which ought to be the same), differ. With the 4-arg variant leaving behind that part of the string that has been extracted (replaced), which is consistent with the documentation: "Extracts a substring out of EXPR and returns it.". Whereas the lvalue variant returns '' (null string).

But that aside, the resultant state of the affected variable ($x) is identical. I contend that the two forms should be syntactic variations only producing identical semantic results, with identical performance.

Update: The revised benchmark shows the next paragraph to be the result of a bad benchmarking. But the performance differential between lvalue-substr and 4-arg substr remains

I further contend that the performance differential between the two forms constitutes a bug! That the single opcode for the lvalue variant, takes longer to execute than the 3 opcodes of the reverse-chop-reverse mechanism, regardless of the length of the string, is to my mind, strongly indicative of a major flaw in the implementation of what should be an identical operation to the 4-arg substr variant.

I've taken a look inside the source code for pp_substr, but frankly, I do not understand the macro-machinations that go on in there.