I would have expected any series attempting to address optimizing Erlang applications to have introduced and used cprof, eprof, and fprof. That said, looking f

I would have expected any series attempting to address optimizing Erlang applications to have introduced and used cprof, eprof, and fprof. That said, looking forward to additional installments. Also, I can totally hear somebody saying, "That's premature optimization, don't worry about it." with respect to that horrible way of getting the application's version number. Stuff like that drives me nuts, and this particular issue is a perfect example of why that blanket statement is so misguided. Yeah, your broken, slow, locally isolated implementation of a thing is innocuous in and of itself... but then some functionality in the critical path uses it and builds on top of it, and then there end up being dozens or hundreds of similar problems and internal dependencies... before you know it you've got death by a trillion tiny cuts. In the pathological case those trillion tiny cuts start to look like noise rather than signal when profiling because nothing interesting just jumps out as critically broken, and you're left just assuming, "Well I guess it's slow just because the language/runtime/machine/whatever is slow, not because I've ground performance down to a fine dust through accreted questionable decisions."