Perl is a pretty high level language. It’s optimized to handle cases like the one you’re referring to with decent efficiency, but makes little provision for low level techniques. foreach(LIST){$_} is faster than for($i=0;$i++;$i<@arr){$arr[$i]}; writing your own code to sort data is pretty much doomed to be slower than sort; goto is very slow, function calls aren’t nearly as much; the list goes on.
The fastest way to do something in Perl is frequently the one that implements the most costly step in the fewest ops. That’s why a Guttman-Rosler transform is faster than a straight Schwartzian transform for complex records, f.ex – because the costly operation is the sort, and the GRT does not burden that one with callback.
It is therefore no surprise that BrowserUk’s tests with substr failed to improve performance. Perl’s process of locating a specific byte in a scalar’s long string – where scalars are a multiply indirect structure to allow seamless growth –, creating an lvalue for it, and then assigning to that lvalue is far more involved than C’s simple process of doing some pointer math and dereferencing the result.
Perl is not C. The most efficient way of doing things in Perl is almost always to let the perl interpreter do as much of the job as possible, rather than spelling it out.
Makeshifts last the longest.
In reply to Re: what's faster than .=
by Aristotle
in thread what's faster than .=
by xafwodahs
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |