Hello!
One of the BEAM's great strengths is it concurrent garbage collection that never does "stop the world" pauses. It is a big part of why Erlang based systems have excellent P99 latency compared to other mainstream languages and runtimes.
The newly introduced persistent_term breaks that rule, and any time a value is removed from it the VM as a whole has to be paused in order to mutate this shared data. Because of this (and some other performance related reasons) it should be used very sparingly, and likely it should only ever be appended to.
For data and configuration that changes ETS is the go-to shared store, and it is used by the logger, the application configuration system, etc. I think it would be good if this package used one of those existing configuration systems, or if it used ETS directly.
If PT is to be used as a mutable store then the functions that mutate it need to have a clear warning explaining the consequences of calling them, so the programmer can understand what will happen and hopefully can avoid reduced performance.
Thanks!
Hello again 😃
I'm not gonna lie, the use of persistent term is something I saw in
woofand then briefly looked into. I assumed it would be okay, considering the config should really only be written once at application startup.I'll add a disclaimer to it for the time being, until a proper integration with the erlang logger is implemented 😃
Thank you!