*** SPAM *** Re: Memory usage with ETS

[Peter-Henry Mander]

Hi Uffe,

Thanks for the BIF suggestion. Unfortunately they're not an easy fit to
the purpose I have in mind. I wish to have a fun execute repeatedly at
regular intervals that can fall between millisecond ticks, so that I can
simulate a firing rate at an arbitrary frequency.

The ETS based micro_timer I wrote allows me to specify timer periods in
microseconds. It is true that in reality the timer granularity is
strictly 1000 microseconds, but I'm happy to accept a mean deviation
from the desired rate (or jitter) of 500 microsecond. If I wanted
stricter control I would need a C link-in driver (or write the whole
project in C *shudder*) and twiddle the OS timer parameters to suit.

The fact I can bundle an environment into a fun and let the initiating
process die means that I reduce the process footprint drastically while
it does nothing; it's gone!

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.

The fun storage in ETS is certainly not negligable, but I've had
programs that consumed vast amounts of memory in many thousands of
processes simply waiting (and hibernating) for a trigger message to come
in, which was followed by a huge message storm which impacted
performance. Admittedly my design was crap, I'm still learning.

Pete.

On Fri, 2005-08-05 at 22:24 +0200, Ulf Wiger wrote:
> Den 2005-08-05 19:16:53 skrev Peter-Henry Mander  
> <erlang@REDACTED>:
> 
> > For example, I've rewritten the timer module so that I can specify timer
> > periods with microsecond granularity to enable issuing messages at rates
> > of, say 333 cps (the timer approximates the period to the nearest
> > millisecond and will achieve 333 cps on average). I've used ETS to store
> > the timer sequence since inserting into lists gets very costly as the
> > number and frequency of the timers increases. I haven't run the timer
> > for very long but I suspect the ETS table will grow monotonically. How
> > can I reduce the memory footprint without resorting to table copying
> > which will disrupt the timer?
> 
> Here's a suggestion: skip the timer module and use the
> timer BIFs instead. Actually, even starting a regular process
> per timer is much more efficient than using the timer module,
> and the BIFs erlang:send_after/3 and erlang:start_timer/3
> are *much* more efficient and scale very well.
> 
> /Uffe