Exercism states, that I should rather capture a function instead of creating a new one.
While this makes sense, it seems to me that this should be an easy task for the compiler to optimize.
In particular I prefer for example &(&1+&2) over &+/2.
1 Like
It is not faster. Those are equivalent. 
10 Likes
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:
3 Likes
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?
Seems like it’s a runtime warning when attaching, not a compiler warning.
1 Like
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.
2 Likes
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.
1 Like
To the contrary. One of the big features of telemetry is that handlers are executed in the process emiting any event, which means there’s no message passing involved in providing data to said handlers – and handlers can then decide how to handle the provided data. That however means the handler is passed around between processes.
2 Likes
Interesting. Any good starting pointers on code to read? Same repo as you sent a link to earlier, surely, but probably also concrete implementations e.g. Prometheus, Zipkin, Jaeger etc. adapters?
/CC @hauleth
