Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Re^4: Cheap idioms

by Aristotle (Chancellor)
on Oct 17, 2002 at 13:24 UTC ( [id://206013] : note . print w/replies, xml ) Need Help??

in reply to Re: Re: (tye)Re: Cheap idioms
in thread Cheap idioms

Don't even think about it. If any of those even is consistently more efficient, the difference will be so small it is hardly going to matter. The key here is that it's a very concise way of doing what it does. In this case it is a oneliner, but in general, it doesn't matter how many lines an idiom takes (the Schwartzian Transform rarely fits in a single line, f.ex) - just that it is concise way of expressing a certain action. Don't confuse that with golfing: an idiom is not about saving keystrokes, it is about saving "brain cycles". The idea is that a) it is conveniently short so that people do use it and b) when you see it used in a snippet, you immediately know what it does just by the unique look of it.

It simplifies communication between the original programmer and the maintainer of his code.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: Re^4: Cheap idioms
by Sihal (Pilgrim) on Oct 17, 2002 at 13:48 UTC
    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.

      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!? 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.