http://qs1969.pair.com?node_id=206021


in reply to Re^4: Cheap idioms
in thread Cheap idioms

OK! thanx. I agree that it is visually much more readable and I thought well, if it is faster also, cool. but i don't agree with you on one point: if it is even 1% faster, i'll take it for a script that has to process 100 000 files in a row.
Otherwise, for little scripts (read that process very little data)
I agree, I won't bother.

Replies are listed 'Best First'.
Re^6: Cheap idioms
by Aristotle (Chancellor) on Oct 17, 2002 at 14:06 UTC

    Well, you have a point about the 100,000 files - at first glance. But - if you are processing 100,000 files, is the slurp idiom really the best place to optimize? Don't you think you will be able to get much more than a 1% per-file-open speed up by optimizing some other, more heavily used part of the script? And if you really have optimized all else so well that the file slurp can make any difference - maybe you should be using C, instead of Perl.

    Remember - premature optimization is the root of all evil. Don't optimize before you need to. The corrolary of this is that you shouldn't try to micro-optimize parts of the script in anticipation of possible performance bottlenecks. When you do hit one, profile your script and work on the most processing intensive part.

    Remember: programs are letters from one programmer to another. The fact that computers can execute them is only incidental.

    Makeshifts last the longest.

      ... programs are letters from one programmer to another. The fact that computers can execute them is only
      incidental.

      Incidental!? What bunk!

      Few programs would exist if they did not perform desired functions by being executed.

      The readability of programs enhances their utility as tools and examples for programmers, but is a side issue.
      Side issues can be important, no one buys a car just on the basis of it performing its primary purpose.

        "Always write your code as if the next maintainer will be a homicidal maniac who knows where you live."

        That saying is not bunk at all. A completely unreadable source is of no use to anyone, regardless how optimized it is. What does it do? Do you know? How will you find an error if there is one? How do you know what is an error or not?

        The foremost issue is writing legible code. The fact that you are writing Perl alone, as opposed to C or assembly, means you cannot be extraordinarily concerned with performance to begin with. So if you chose Perl over C, why was that? Now take the next logical conclusion and you'll see that code legibility being more important than optimization logically follows.

        Makeshifts last the longest.