It is not faster. Those are equivalent.

There’s however a difference between &Module.fun/2 vs. any other form. The fully quantified version (mod, fun and arity) can be optimized to not use an anonymous function, which makes it more performant. This is important in situations like :telementry handlers, which might be called very often, as described in the docs:

Great point. Maybe long-term Erlang should add NIFs / BIFs that deal with telemetry handlers so people don’t have to step on egg shells.

You’ll get compiler warnings when doing this wrong with telemetry afaik.

Really? How do they do it, compiler tracers?

https://github.com/beam-telemetry/telemetry/commit/a2e98a6474212a518fd1406d457e39839ae51e0b#diff-ae92aa66910b0a33615d1d3207fc0552b2a270776b5afec936f1f668adef4dbbR98

Seems like it’s a runtime warning when attaching, not a compiler warning.

Really thoughtful of them to implement this warning. Impressive.

Thanks for the link.

To clarify - difference is meaningful only when that capture crosses process boundary. Within single process it will be unnoticeable or even may be slightly slower when you call local capture within single module.

But doesn’t it always cross the process boundary? I thought telemetry sending is always async (as in, it’s sending messages to another process)?

Hmmm. Soon I’ll be working on several projects that will all need a lot of telemetry and I should research the performance implications in more detail.

Still, anything you can tell me beforehand will help.

In Telemetry it almost always cross process boundary, that is why Telemetry forces remote captures.