Changing anything in persistent_term means running a GC over all the processes in the system and copying all of the data in persistent_term. It can get very expensive on bigger systems.

One thing to ask is, if it would be actually beneficial. Binaries (and I assume your entries are just plain binaries) are stored off-heap, so they are not copied when retrieved from ETS anyway. This removes the biggest advantage of persistent_term over plain old ETS.

Think of it this way: If it’s something you would normally compile ‘into’ a models code for efficiency then use it, else you probably want ETS (or mnesia to keep it serialized to disk and hold it in memory on load).

So for a blog I’d personally use either flat-files on disk or store it in mnesia with disk and memory copies, I’m not sure I’d use this for that, though your data is static enough that it ‘should’ be fine.

Just remember, :persistent_term has a max storage size of 1 gig unless you set the _MIscs 2048 or so option (that one would raise it to 2 gigs, the value is in megabytes).

When a new value is put then it is visible everywhere immediately on the node because when an old value is replaced or erased then a global garbage collection is run, which can pause things, that collection will replace any links to the global data in all processes to a local copy of the data instead.

Just remember that accessing data in :persistant_term is way fast, but changing data in any way is very slow, and in some cases it can be really really slow. But it’s still faster than recompiling a module to ‘intern’ the terms (which would destroy linked processes if it got updated, so :persistent_term is definitely better there).

Hi there, I created a Hex package to experiment for distributed code compilation within an Elixir cluster which would take away the “pain” of writing: https://github.com/archan937/clustorage

I actually started building this with Discord’s FastGlobal package as inspiration.

I’m curious for your thoughts about it

Are their any anecdotes yet reflecting relative performance of :persistent_term versus functions that bake in data?

:persistent_term looks like a possible good approach for storing locale data in my ex_cldr package since its large and static. However it is a fairly complex Map.t() so their would be some penalty to pay in keeping the data as one large map as apposed to the current approach which decomposes the map into different functions.