this sounds suspicious. bits of code are going to be walking the whole process tree looking for something that is not going to be there when the code is running in production. i guess the operation is relatively inexpensive so maybe it is ok.
Hey, I wrote the blog post under discussion. It's good to bring suspicions! But yeah, the rarest situations aside, there's not going to be any relevant performance impact.
For one thing, in production, for a given key, the process tree will be "climbed" only once by any calling process. Thereafter, ProcessTree will cache, in the process dictionary of the calling process, either the value it "finds" in the tree, or a provided default value. For any later requests for the data, the calling process will find the cached value in its own process dictionary with a single, local lookup.
Along with persistent terms, a process looking in its own dictionary is as fast as data access gets on the BEAM. Faster, for example, than reading from the global application environment. In situations that warrant micro-optimization, the process dictionary is something to be leaned into, not away from.
In considering the initial "climb", we're talking about accessing the dictionaries of maybe 10-ish parent processes. In typical situations like mounting a LiveView, time spent climbing the tree will be dwarfed by other factors.
The main theoretical performance issue of climbing the tree is copying the full contents of other processes' dictionaries into the space of the calling process. Unless there's drastically large amounts of data in the parent dictionaries, it's not going to matter. Even then, OTP 26.2 introduced a new API for accessing specific keys in the dictionaries of other processes. Once an upcoming Elixir release supports 26.2, ProcessTree will integrate the new API, and the theoretical impact of copying full dictionaries will no longer be an issue.
