Should instrument.erl be in runtime_tools instead of tools?

In my mind, tools is about tooling that you wouldn’t want to run in production, either because it is expensive (fprof) or because it is specific to environments live dev (erlang.el) and test (cover).

However, I believe instrument.erl would be fine in production? Perhaps observer could even have a page or a subsection using the results of instrument.erl to help debug memory allocation.

Does that make sense? Or would it be a idea to invoke the results of instrument.erl from Observer?

5 Likes

That makes sense to me since I use instrument at runtime in production all the time :slight_smile: It may even be worth calling tools something else in the future so that’s it quite clear that these are not tools you generally ever want to use in production.

3 Likes

John mentioned that it is ok to run instrument in production because it spreads the cost over time, but not contiguously. So if it is to be added to Observer, it needs to be done behind a button or similar. I submitted a PR for further consideration: Move instrument.erl to runtime_tools by josevalim · Pull Request #6829 · erlang/otp · GitHub

2 Likes