[erlang-questions] Memory-effective queue handling

Attila Rajmund Nohl <>
Wed Jul 25 15:44:35 CEST 2012


2012/7/25 Richard Carlsson <>:
[...]
> You'd only run out of space if the queue is so long that you don't have
> memory enough to call lists:reverse() on the current in-half of the queue
> (and after that, the old queue will immediately become garbage). Can that
> really be the case?

It might happen. According to the crash dump the process in question uses
Stack+heap: 228065700

words of memory. I store a tuple of bigint and a small integer in the
queue, and the queue is essentially a list (actually two lists, but
doesn't matter), so one entry in the queue costs 2+3(?)+1+1=7 words.
The process has some other stuff in its state, but that should be
negligible. The erlang VM run for less than 13 hours. If I calculate
correctly, this means that there should be around 600 events per
second though 13 hours to reach this amount of memory. After some
internal conversation I think it is possible that due to an unrelated
bug I do get this much events.

> But you should be able to improve the behaviour of the above code by using
> queue:peek_r(Q) instead of queue:out(Q), and then call queue:drop_r(Q) in
> the second case clause only, so no rewriting of the queue representation is
> done unless necessary.

Thanks.



More information about the erlang-questions mailing list