Re: persistent_term to replace ETS for caching

"Richard O'Keefe" <[email protected]>
Newsgroups gmane.comp.lang.erlang.general
Message-ID <CABcYAdJQ=5sezVoWC48N=CFGsE-R4zh7KFzGbgjJpvgHxoRgdg@mail.gmail.com>
Thanks for that advice about persistent_term.
From the documentation,
<quote>
When a persistent term is updated or deleted, a global garbage collection
pass is run to scan all processes for the deleted term, and to copy it into
each process that still uses it.
</quote>
Do I understand correctly that if three processes refer
to a persistent-term, and one of them deletes it, it
will be copied into both of the other processes, thus
INCREASING the amount of memory used?
This is sufficiently counter-intuitive that I am not
sure I would dare to use this feature.

Do I further understand correctly that *adding* a new
persistent-term does NOT force garbage collection?


On Mon, 7 Dec 2020 at 00:49, Nalin Ranjan <[email protected]> wrote:

> It has the potential to trigger Global GC, and can affect responsiveness
> as per the docs.
>
> https://erlang.org/doc/man/persistent_term.html
>
> Regards
> Nalin Ranjan
>
> On Sun, Dec 6, 2020 at 5:16 AM Frank Muller <[email protected]>
> wrote:
>
>> Hi guys,
>>
>> At work, we cache about 5.3 million entries in ETS. The system works
>> perfectly, no issue so far (many years).
>>
>> During a brainstorming session, a colleague suggested to switch to
>> persistent_term instead to avoid ETS term copying.
>>
>> Pretty simple: we check if the Key exists in persistent_term. If yes, we
>> are done. If not, we get it from ETS, move it to persistent_term and send
>> it back to the caller.
>>
>> Question: is there any limitation(s) on persistent_term usage? Stated
>> otherwise, can we create 5.3 million persistent_term <K,V>?
>>
>> Any suggestion/idea/thought is very welcome.
>>
>> /Frank
>>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.