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

[Alexander Wingård]

Joes words are very wise, however in the world of commercial software
development; there are a lot of things that have higher priority than
performance: Meeting deadlines, implementing new features and not
messing with things that work.

Since you are working with Erlang, chances are that your project seem
very small at the time but will be a huge success in the future ;) so
answering questions like "How often does your code get called?" might
be harder than you think. I would like to emphasize Mike Williams
saying:
"If you don't run experiments before you start designing a new system,
your entire system will be an experiment!"

In the previously posted code, choosing either one of them won't
really affect the maintainability of the program. In Erlang, there are
often many ways to achieve the same result with different performance.

Another problem with bad performing code is that it might be hard to
find it later and the easiest solution might be to throw hardware at
the problem and sometimes, that even make matters worse (multiple
producers, one consumer for example).

So with this I would like to drop a revised statement:
Premature optimization might be the only optimization you will ever
get paid to do.

Alexander.


On Mon, May 18, 2009 at 4:46 PM, Dennis Byrne <dennisbyrne@REDACTED> wrote:
> Yes, I agree with this. I put it in a certain category of "classic
> mistakes", such as the 'big rewrite' or the assumption that doubling a
> team size will result in a 2x improvement in productivity.  I have
> however it a little helpful to know a thing or two about the
> compiler/runtime optimizations of a platform because it often allows
> me to convince others just how silly some optimization efforts are.
> They are also just plain fascinating.
>
> Dennis
>
> On Mon, May 18, 2009 at 5:48 AM, Joe Armstrong <erlang@REDACTED> wrote:
>> 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 <v@REDACTED> 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: erlang-questions-bounces@REDACTED
>>> [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Dennis Byrne
>>> Sent: 17 May 2009 07:12 PM
>>> To: erlang-questions@REDACTED
>>> 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
>>> erlang-questions@REDACTED
>>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>
>
>
> --
> Dennis Byrne
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>