[erlang-questions] ets vs list

[Robert Virding]

All data in an ets table will be garbage collected! It is perfectly
safe to insert and delete data as often as you need.

What Ulf meant was that an ets table is not garbage collected in the
same way as a normal process and that you don't run into same problems
with overly long garbage collections times as you can with a processes
that have a *LOT* of local data. This is why it is safe to have large
ets tables and why you should be careful in having *LARGE* databases
as local data to a process. This is a problem using dict, gb_trees and
array, and lists.

The downside of this is that data has to be copied from an ets table
into the process heap before it can be used, which is why we have
ets:match and ets:select which allow you to perform more tests on
potential data before copying them into the process heap. This is a
benefit using dict, gb_trees and array, and lists.

So they are all *safe* but perform differently.

Robert


On 13 September 2010 16:41, Morten Krogh <mk@REDACTED> wrote:
>  What exactly does it mean that data residing in ets isn't garbage
> collected?
>
> Does it mean that if a {key, Value} pair is in the ets table T,
> and I write
>
> ets:delete(T, Key)
>
> then Value will not be garbage collected.
>
> Morten.
>
> On 9/13/10 4:29 PM, Ulf Wiger wrote:
>>
>> On 09/13/2010 02:58 PM, Max Lapshin wrote:
>>>
>>> 2) what ets is for, if list is fast enough on inserts?
>>
>> The main unique feature of ets is that data residing in
>> ets is not garbage-collected.
>>
>> Roughly speaking, the cost of GC is proportional to the
>> amount of live data, so if you have very large data sets,
>> process heap-based data will have an increasing hidden
>> cost in GC sweep/copy time, even though access times may
>> look excellent in benchmarks.
>>
>> Running benchmarks for longer periods should allow you
>> to include amortized GC cost in the results, but you
>> will also get a bunch of other noise. Tracing on GC
>> events with timestamps may be a more accurate method.
>>
>> BR,
>> Ulf
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>