In the most perfect of all worlds this document would not be needed. The compiler would be able to make all necessary optimizations. Alas the world is not perfect!
All considerations for efficiency are more or less
implementation dependent. Efficient code is not always good code
from the perspective of generality, ease of understanding and
maintaining. Therefor programming becomes a balance act between
generality and efficiency. So how do we manage to walk on the
lim and not fall off? Well, on a structural level there are
things that you can keep in mind while you design your code.
This guide will try to help you use data structures and
mechanisms of Erlang/OTP in the intended way, this will help you
avoid many unnecessary bottlenecks. Apart from those structal
considerations, you should never optimize before you profiled
your code and found the bottlenecks. Also remember not all code
is time critical, if it does not matter if takes a few seconds
more or less there is no point in trying to optimize
it. Profiling erlang code is easy using tools such as
eprof
, fprof
(from release 8 and forward) and
cover.
Using these tools are just a matter of calling a
few functions in the respective library modules. Taking the
appropriate measures to speed the code up once you found the
bottlenecks can be a bit harder. You may have to invent new
algorithms or in other ways restructure your program. This guide
will give you some background knowledge to be able to come up
with solutions.
![]() |
For the sake of readability, the example code has been kept as simple as possible. It does not include functionality such as error handling, which might be vital in a real-life system. Inspiration for the examples is taken from code that has existed in real projects. |
It is assumed that the reader is familiar with the Erlang programming language and concepts of OTP.