What tools should I use to inspect Erlang beams?
What kind of programming should I do to write efficient code in Erlang?
A link is fine.
thank you.
4 Likes
For the inspection part, have you looked at e.g. Erlang -- beam_lib?
As for efficiency, there’s an official guide at Erlang -- Efficiency Guide. There’s a chapter there on profiling, too.
Bonus: here’s a quote from Joe Armstrong on efficiency 
Make it work, then make it beautiful, then if you really, really have to, make it fast. 90% of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!
8 Likes
I am excited to use Erlang 25’s better perf integration, I’ve yet to have an excuse to use it.
3 Likes
Indeed, perf for profiling in the dev environment and perhaps ad-hoc in prod for a few seconds, but also https://www.parca.dev/ or something similar for continuous production profiling.
5 Likes
Is Parca capable of resolving the individual erlang & application function symbols during its continual runtime monitoring? That sounds pretty cool actually.
1 Like
Yes, if you set +JPperf true, it should just work.
Here’s a test app: https://github.com/parca-dev/parca-demo/tree/main/erlang
Some history/discussion of Erlang support: Elixir/Erlang VM support · Issue #145 · parca-dev/parca-agent · GitHub
4 Likes
I’d like to add to this. At work recently we’ve made good use of lttng. I wonder what others thoughts are on lttng. OTP has good support for lltng. I kind of see lttng as good for user space tracing (though it’s capable of system tracing), and perf is the go to tool for me for system tracing.
4 Likes
I have no experience with lttng whatsoever (even outside of the OTP context) but I’d love to know more about how you used it / what you used it for.
I did use the DTrace support a few times (mostly for some garbage collection related tracing) and I certainly wondered about eBPF support a few times (with no significant eBPF experience, it was mostly “I wonder if we could trace this with bpftrace, if we had eBPF support”, I don’t know how much it would actually help).
2 Likes
Honestly, my co-worker via Erlang Solutions can comment on this as I’ve only seen some cool results vs gotten my hands super dirty. He’s on his way
3 Likes
Thanks @starbelly for pointing me to this thread!
I have tried Erlang integration with DTrace, SystemTap, and LTTng.
From my experience, LTTng is the easiest to setup and use, lightweight on the system, and has more features.
You can trace pretty much everything that erlang:trace/3 has (for process-related events, referred to in docs as Dyntrace tracepoints) plus BEAM events (referred to as BEAM tracepoints). And you can trace kernel events in the same LTTng session too, which would hopefully allow for some correlation analysis.
6 Likes
The only thing I’d add to Paulo’s great answer is that I found eprof useful when faced with performance mysteries.
1 Like
What kind of programming should I do to write efficient code in Erlang?
I’ve found the Erlang Efficiency Guide to be helpful.
For profiling, I’ve found the Linux perf integration to be really good. Relative to cprof/eprof/fprof, it has a much lower overhead, and shows both Erlang code and native code, so, for example, you see time spent garbage collecting in the profile too, which I think is useful signal.
There’s a bunch of quirks of Erlang that can be handy to know, e.g. the dedicated map syntax is faster than the corresponding functions, how your code needs to be structured to make use of the binary optimisations, and the efficiency guide does cover these all pretty well, imho.
In terms of straight-line performance, that’s not really the BEAM’s forte, so to be making the most of the BEAM it’s great if you have a problem can you can naturally formulate in terms of lots of processes, at which point it will really shine.
2 Likes