[erlang-questions] At what point am I "playing compiler"

Joe Armstrong <>
Mon May 18 12:48:55 CEST 2009


Thus spoke ye great masters:

 [Kernighan and Plauger:
   Elements of programming style 1974]

    "Write clearly - don't be too clever"
    "make it right before you make it faster"
    "keep it right when you make it faster"
    "make it clear before you make it faster"
    "don't sacrifice clarity for small gains in 'efficiency'"
    "Don't diddle code to make it faster - find a better algorithm"

Knuth, quoting Hoare,  blessed be their names, spoke thus:

"We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil.

Knuth also wrote (though I can't find the reference) that it was not
worth optimising
something that got called less that 10^9 times (I think that's right)
- he wrote that something like 20 years ago, so today the advice must
be 10^12 times :-)

I once met a guy who was optimizing a large FORTRAN program
he was going to shave 10 minutes off a three hour batch job. I asked how often
the program would be run - "about once every three months" - I asked
him why he was doing this - "because I'm paid to do it"

                                                              - o O o -

At the start of any project you should have a time budget - the person who
commission the code should say "this code must do its job in N seconds".

Your job is to write code that is as clear as possible that executes
in under N seconds.

So you write your code as clearly as possible, then time the code. If the time
is under N you stop - otherwise you measure where the time goes and optimize.

To go back to you original question:

           How often does you code get called? - how fast should it be?

If you answer "Dunno" and "as fast as possible" then my answer would be
"since you don't know how often the code is to be called then choose
the clearest
solution"

If you know the answers then you can measure and see if your code is
fast enough -
then you choose the clearest version that is fast enough.

Without knowing how fast it should take you cannot answer the question
"is this fast enough".

This is the difference between a specification and an
implementation. The specification tells you how fast it should take,
what it should do etc. The implementation tells you what it actually does.

An implementation is only correct with respect to a specification - without
a specification the notion of "best anything" is meaningless.

Why do we want the "clearest version" - because most of the time
efficiency is irrelevant (Knuths 97% figure ...) - and most of the time the
largest cost of a program is in maintenance where understanding what
the code means
is vital.


/Joe



On Mon, May 18, 2009 at 8:38 AM, Valentin Micic <> wrote:
> Was it Joe's rule that goes like this:
>
> "Make it run first, and then optimize later -- only if you have to"
>
> Stick to this rule, and the life will be good to you.
>
> V.
>
> -----Original Message-----
> From: 
> [mailto:] On Behalf Of Dennis Byrne
> Sent: 17 May 2009 07:12 PM
> To: 
> Subject: [erlang-questions] At what point am I "playing compiler"
>
> The functions expressive/0 and efficient/0 have the same result.
> Sometimes I prefer expressive syntax but I am concerned about
> efficiency.  Should Erlang developers worry about this or do any of
> the compilers (or runtime) make these concerns obselete?
>
> expressive() ->
>        List = [1,2,3],
>        Last = lists:last(List),
>        Min = lists:foldl(fun min/2, Last, List),
>        Max = lists:foldl(fun max/2, Last, List),
>        Sum = lists:foldl(fun sum/2, 0, List),
>        {Min, Max, Sum}.
>
> efficient() ->
>        List = [1,2,3],
>        Last = lists:last(List),
>        lists:foldl(fun summary/2, {Last, Last, 0}, List).
>
> summary(X, {Min, Max, Total}) ->
>        {min(X, Min), max(X, Max), Total + X}.
>
> sum(X, Y) ->
>        X + Y.
>
> min(X, Y) when X < Y ->
>        X;
> min(_, Y) ->
>        Y.
>
> max(X, Y) when X > Y ->
>        X;
> max(_, Y) ->
>        Y.
>
> --
> Dennis Byrne
> _______________________________________________
> erlang-questions mailing list
> 
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
> _______________________________________________
> erlang-questions mailing list
> 
> http://www.erlang.org/mailman/listinfo/erlang-questions
>



More information about the erlang-questions mailing list