Memory usage with ETS

[Ulf Wiger]

Den 2005-08-05 19:16:53 skrev Peter-Henry Mander  
<erlang@REDACTED>:

> I've carried out a little experiment. The program I've written
> originally used several ETS tables throughout it's processing lifetime,
> and memory consumption grew gradually as it progressed.

BTW, I recall that this was a bug long ago (ETS didn't allocate
memory in a fibonacci sequence like the processes did, and therefore
fragmented memory; another variation was fix_alloc:ing objects
that were stored in ETS, but in a way that long-lived objects
could "partition" memory space, which led to fragmentation.(*))
I don't know if any such bug has re-appeared...?

ETS tables dynamically expand, but they should also shrink
dynamically (with a hysteresis.) Are you sure you don't have
a memory leak in the sense that you have lingering objects
that should have been deleted?

(*) Apologies if my description of these bugs is ridicuously
flawed -- in any event, there were problems with ETS and
memory fragmentation a few years ago.


> I'm aware of hibernate, which does a fine job of reducing the process
> memory footprint when idle (but is it as small as a fun?), I also wanted
> to reduce the number of messages bursting around the system.

Hibernate in a process holding only a fun should be quite close to the
memory footprint of the same fun in an ETS table. Note that if you
create the process with a proc_lib function, you will get some stuff
in the process dictionary that, while being useful for debugging,
of course will increase the footprint. Hibernate doesn't empty the
process dictionary.

Regarding the number of messages, using spawn/hibernate is going to
use less CPU power than the timer.erl module. That should be the
important part (that, and memory, of course).

/Uffe
-- 
Ulf Wiger