[erlang-questions] performance drop in R15A?

[Tomas Abrahamsson]

Nico Kruber wrote:
NK>>>>>> With our internal benchmarks ("make bench") showed a drop of
NK>>>>>> around 15% in performance compared to R14B04. [...]

NK>> The performance drop of the recent R15 checkout compared to R14B04 in our
NK>> application is now at _30%_ compared to a drop of "only" 15% in R15A!

Kenneth Lundin wrote:
KL> When working with R15B we are of course performing a number of
KL> bencmarks to keep track of the performance.
KL>
KL> Whe always strive to improve general performance in each release AND
KL> OUR BENCHMARKS INDICATE THAT R15B IS FASTER IN GENERAL THAN R14B04.
KL>
KL> It is however always possible that some specific operations or
KL> combinations of operations get slower while others are optimized.

Hi,

  we're currently prototyping an simulator for mobile
telephony. Performance is one of our main goals, so
we've been measuring with both R14B04, R15A.pre and
with OTP from github.

We, too, have seen a performance drop similar to what
Nico has observed, although not as drastic. We try to
start a number of UEs, each UE is a few processes
passing a sequence of messages back and forth, then we
measure how many UEs a certain machine can handle,
given a fixed rate of how often they sould pass the
messages. This is what we've seen (higher number means
better performance):

  - R14B04:          12200
  - R15A.pre:        11800  (== git rev e21ff9b)
  - git rev 6971b96: 11500

The workload for the processes consists of NAS TLV
encoding and decoding (bit/binary manipulations), a
fair bit of ASN.1 encoding and decoding, and some
ciphering/deciphering using the crypto lib.

KL> Regarding the findings for this particular application we think the
KL> reason for slowdown is a very frequent but non typical usage pattern
KL> that now becomes visible as a performance bottleneck.

It might well be that our usage pattern, is a bit away
from normal (currently, we hope so, but we fear it
might not be!) We'll arrange to send the source code
for our benchmark off-list, in case you would want to
repeat it.

BRs
Tomas