Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re: what's faster than .=

by Aristotle (Chancellor)
on Mar 08, 2003 at 13:50 UTC ( [id://241385]=note: print w/replies, xml ) Need Help??


in reply to what's faster than .=

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.

Replies are listed 'Best First'.
Re: Re: what's faster than .=
by BrowserUk (Patriarch) on Mar 08, 2003 at 19:13 UTC

    creating an lvalue for it and assigning to that lvalue is a far more involved than C's simple process of doing some pointer math

    Agreed. In part, that's why I hoped (forelornly it seems) that Perl 6 would allow the syntax $string[n] as an lvalue or rvalue to mean the same as substr($string, n, 1) once that syntax no longer conflicts with the @arrayn syntax.

    From my best guess, and I realise that it is only a guess, the compiler should have enough information at compile-time to convert $string[n] =  'c' or even $string[n..m] into a direct read-from or write-to the scalar's storage without the need to generate a perl lvalue structure unless a reference is being taken.

    Avoiding both the call overhead of substr and the need for generating the whole lvalue and associated paraphanalia, unless it is necessary, would allow bytewise manipulation of strings with significantly less overhead than is currently the case.

    It is possible that this lack of direct access at the byte level of strings that allows perl to accomodate changes like unicode with almost no changes to the visible api's which is nice.

    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.

    Perl's high-level constructs do obviate the need to do many things at the byte-wise level, but will never obviate them all.


    Examine what is said, not who speaks.
    1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
    2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
    3) Any sufficiently advanced technology is indistinguishable from magic.
    Arthur C. Clarke.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://241385]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (4)
As of 2024-07-22 21:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?
    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.