in reply to Which way is faster?

I agree with the point profile before optimize. I would even go further:

1. 98.765% of all programming task do not need a special focus on the fastest code.

2. Most times the compiler does a better optimization job than you. (What does the Perl interpreter?)

3. It is more important to spend time on a clean program structure to enable support.

Ad 1)
What type of programs or script does the normal human write? Does it really matter if a script finishes after 5 minutes or 4min55 ? If an optimization gives 3m to a program, it was formerly bad designed and should not be optimized, but restructured. Maybe GUI-callbacks to verify an entry? If you check every field against a database it will be slow, but as above, redesign not optimization is necessary. The rest are special cases, like games, os-kernels, often/many running scripts, Perl interpreters etc.

Ad 2)
Since the time I analyzed assembler output of a C compiler to find bugs in the RT-Library, I leave most things to the compiler. It made no difference wether to dereference a pointer over some levels or use a local variable and one line of code more, both resulted in the same code using CPU registers. (Any knowledge, what Perl does?) But the second version was readable, this leads to my next point!

ad 3)
Optimized code is most times only readable with the help of the brains who invented that. What if he is not available (well, my experience is that it is most times he, not she) or can't remeber what he thought 6 months ago? Invest weeks to fix a bug? Throw away the code and rewrite it? What estimation do you give your customer, what to your boss about your working results? For some microseconds to rotate a logfile? If you write clean code, well structured constructs (loops) the code-flow becomes understandable and is therefore easier to maintain, which includes maybe optimization.
Oh, I forgot. Use strict, it is most times more important than your optimization, which work only without strict.

regards Brutha

Confession:
I named Basic Variables 'a1', 'a2' to let the interpreter find them faster. That was about 20 years ago on a apple][

Replies are listed 'Best First'.
Re: Structure is more important than speed
by Anonymous Monk on Sep 09, 2002 at 11:39 UTC
    The Perl interpreter is about as stupid as you can get.

    Optimization is done at compile time, and compile time is seen as run time, so little optimization is done. Shorter variable names and hash keys are faster. If you throw away warnings you can double speed with 

    if (defined(my $foo = exists $lookup{$bar})) {
    ....
}

    [download]
    instead of 
    if (exists $lookup{$bar}) {
    my $foo = $lookup{$bar};
    ...
}

    [download]
    In looping through nested data structures you gain speed by pulling out substructures once rather than doing nested lookups. Bonus: this may be clearer. 
    for my $foo (sort keys %some_hash) {
    my $by_foo = $some_hash{$foo};
    for my $bar (sort keys %$by_foo) {
        my $by_bar = $by_foo->{$bar};
        for my $baz (sort keys %$by_bar) {
            ...
        }
    }
}

    [download]
    You can travel synchronized data structures in parallel rather than traversing one and doing hash lookups to find the other.

    Good news! Using strict encourages fast lexicals.

    Yes, I have needed to know this. A report took 3 hours per period, and needed to take less to finish the total job each night. There is no point in running more CPU-bound processes than one has CPUs. Moore did not arrive in time. So the code ran a half-dozen times faster with limited damage done. I did not rewrite in C.

[reply]
[d/l]
[select]
      If you throw away warnings you can double speed with 
      if (defined(my $foo = exists $lookup{$bar})) {
    ....
}

      [download]
      instead of 
      if (exists $lookup{$bar}) {
    my $foo = $lookup{$bar};
    ...
}

      [download]

      Maybe you can, but it hardly matters as they do two entirely different things. The first sets $foo to either 1 or "" (either of which is always defined.)

      -sauoq
"My two cents aren't worth a dime.";
[reply]
[d/l]
[select]
        D'oh. Thinko causing typoing. Make the obvious fix and the comment remains true.
[reply]
Re: Structure is more important than speed
by bronto (Priest) on Sep 10, 2002 at 08:26 UTC

    I totally agree with you, Brutha. Maybe that's because I never had an imperative need to write a strictly optimized code. Instead, I prefer clarity and I always use several lines, e.g.:

    my $copy = $main_variable ;
$copy =~ s/my name/dumb me/g ;

    [download]

    even when one line would easily do. As long as you don't need to suck every cycle out of your (maybe rather old) CPU, it's better to be slower and readable. Especially when your code is likely to survive when you leave your job :-) IMHO

    Ciao!
    --bronto

    # Another Perl edition of a song:
# The End, by The Beatles
END {
  $you->take($love) eq $you->made($love) ;
}

[reply]
[d/l]

In Section Meditations