optimization tricks ?

Hakan Stenholm <>
Fri May 12 19:11:11 CEST 2000


I'm currently working on a strategy game in my spare time (i.e. not a
large distributed real time system) and have spent some time wondering
about how to write efficent (speed and memory vise) erlang code.
I know about tail recursion and last call optimization (allthough
exactly when this ocures seams a bit vauge) and that handling files as
binaries (if posible) can be significantly faster. But I have been
wondering about several things and as erlang was originaly inspired by
prolog these optimization tricks spring to mind:

* in Prolog the order of the predicate (function) clauses affect the
speed of selecting the apropriate clause (first match is used). e.g. :
do_something_per_element([E|Rest]) ->
        do_something(E),
        do_something_per_element(Rest);
do_something_per_element([]) -> ok.

would be faster becouse the first clause is allways the right one expect
in one case (when it is done).
Does this apply to Erlang as well ?

* if the functions clauses use pattern matching in their heads e.g. :
    F1(case_a, D) -> ....
    F1(case_b, D) -> ....

    F2(D, case_a) -> ....
    F2(D, case_b) -> ....

Prolog would be faster for F1 as pattern matching would not be needed
for more than the first argument i.e. keys should be first and placed in
such an order as to reduce the amount of possibal matching function
clauses.
Does this apply to Erlang as well ?
- - - - - - - - - - - - - - - - - - - -

Are there any other non-algoritmic tricks for better perfomance ?
Is pattern matching with atoms faster than strings (i.e. list of
integers which will presumebly need to be matched letter for letter) ?

And yes I _DO_ know that the choice of algoritms is generaly far more
important than tricks that can change the Ordo by some constant    : )

Håkan Stenholm




More information about the erlang-questions mailing list