[erlang-questions] Updating Myths of Erlang Performance

[Joe Armstrong]

This is an excellent suggestion:

Some other myths.For starters:

1) That using cases/if/multiple entry points is somehow more efficient

I've see several posts suggesting that rewriting functions with a
single entry point
conta multiple entry points and so on will be magically more efficient
- when in fact
after compilation the code is pretty much identical.

2) That you can predict performance without doing measurements.
A simple guide to measuring performance might be good here.

3) That inter-process message passing time is constant
(on a big multi-core sending a message across cores can be way less
efficient than
sending across the same core)

4) That thow-away light weight processes should be avoided.

5) That string processing is inefficient (there are even Blog and rants about
Erlangs "string problem" - please tell people to avoid tail-appending
long lists A ++ LongList is a killer when I/O lists are perfect.

6) That Erlang has a string problem - no it doesn't - Erlang has no strings.
It has string literals and lists of integers - and libraries to
serialise lists of
integers into UTF8 byte streams and so on.

Cheers

/Joe



On Sat, Jun 4, 2016 at 8:13 AM, Björn Gustavsson <bjorn@REDACTED> wrote:
> We think that it is time to  update the Myths of Erlang Performance in
> the Efficiency Guide. Some myths have probably died by now and some
> new may have arisen.
>
> I am open to suggestions for myths to retire (move to a separate
> section at very end of the guide) and new myths to add.
>
> Currently, I think that the following myths definitely should be retired.
>
> 2.1  Myth: Funs are Slow
>
> 2.2  Myth: List Comprehensions are Slow
>
> Are any other myths dead?
>
> I am considering adding a new myth, something like this:
>
> "I thought binaries were always faster than lists, so why is binary
> matching slower than list matching?"
>
> Then there should be an example for both binaries and lists, something
> like this:
>
> f(<<B:/8,T/binary>>) ->
>    %% Do something with B.
>    f(T);
> f(<<>>) ->
>    %% Return something.
>
> The answer should be that for more complicated binary patterns, binary
> matching wins, and also that  the cost of using binaries vs. lists in
> the entire application must be considered. Long lists or many short
> lists in many processes will cost more in GC costs; then there are
> different costs for sending binaries vs. lists as messages.
>
>
> Are there any more myths I should consider?
>
> /Björn
>
> --
> Björn Gustavsson, Erlang/OTP, Ericsson AB
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions