Think I figured it out.

Right at the top of my application’s start function, I added:

:fprof.trace([:start, verbose: true, procs: :all])

spawn fn ->
  :timer.sleep(10_000)
  :fprof.trace(:stop)
  :fprof.profile()
  :fprof.analyse(totals: false, dest: 'prof.analysis')
end

the procs: all makes it profile all processes. I stop the trace after 10 second. This generated a 1.5GB fprof.trace file (so, beware!) The calls to profile/analyze generates a very verbose prof.analysis file (37MB). This file can be explored, but it’s noisy.

I used GitHub - isacssouza/erlgrind: Convert fprof to callgring output · GitHub to convert the file to a callgrind format which then lets you use those sets of tools (like http://kcachegrind.sourceforge.net/html/Home.html).

I think there’s also a bit of a culture difference: if you instead search for “elixir metrics” you’ll find quite a number of resources for this. “elixir profiling” not nearly as much. This probably reflects some aspects of the culture around, and cultural heritage that have gone into, Elixir. Aaaanyways …

Here’s a decent tool that looks like it may provide what you are after: Exometer, an Elixir wrapper for it (which I haven’t yet tried myself … so ymmv?), and there are a good number of blog entries out there that talk about these tools as used from Elixir.

There are several other instrumentation-based libraries for gathering and tracking metrics for Elixir out there. That includes a couple of 3rd party services which will host the resulting data and who have nice native Elixir libs. But there are also fully self-hosted solutions that a “elixir metrics” on google will discover

Some random thoughts circling my head about the whole “profiling has a common meaning in other languages / environments”: … wearing my C/C++ (or most other languages I use) hat, yeah I would agree with that. “Profiling” has a fairly static meaning in those contexts.

Elixir’s, or rather the BEAM’s, inherent preemptive code execution (aka processes) and async message passing make a number of traditional profiling techniques and ideas (like “watch how much CPU my app uses pls”) not as clear cut. e.g. in most other platforms I’ve worked with the idea of “hey, can you tell me how many concurrent code paths there are?” is relatively exotic; even in heavily multi-threaded applications I’ve written in C++, I haven’t experienced anywhere near the usual level of dynamic behavior that a typical Elixir application ends up exhibiting which makes tracking / counting / monitoring processes “a thing” that is actually interesting. The preemption can also have interesting effects in more basic measurement techniques in real-world environs, though that can be controlled for in testing environs, but then that lends itself to synthetic micro-benchmarking .. which can be useful, but not always what is needed to demonstrate shipability as artifacts like message bottlenecks will only show up under load.

Yep, fprof is quite comprehensive; ships with Erlang, so is quit well supported (and been around the block a few times) but .. as you found .. it produces some pretty gnarly output. I wasn’t actually aware of erlgrind, though, that’s awesome Definitely will have to use that next time …

p.s. kcachegrind ftw.. have used and loved that app for .. gosh .. i don’t know how many years now.