ETS table with only counters

[Jesper Louis Andersen]

A write is when you are changing a value in the table. A read is when you
are not changing a value in the table. Update counter will change a value
in the table, potentially, so it'll need a write lock rather than a read
lock. Since you typically cannot upgrade a lock in the middle from read to
write, you can assume it needs the write lock. If you never call stuff such
as lookup, match_object, select, match, ... you are always writing,
especially if you only call those when you are pulling out stats and such.
In that case, going for a write_concurrency mode might be beneficial.

On Wed, Nov 25, 2020 at 6:24 PM Frank Muller <frank.muller.erl@REDACTED>
wrote:

> Hi Jesper,
>
> To make it in my mind, my ETS table contains only counters. Following you
> explanation, you consider a table:
>
> 1. write heavy if it mainly uses this kind of updates:
> ets:update_counter(Tab, Counter, {2, N, 0, 0}).
>
> and i should set it to {write_concurrency, true}
>
> 2. read heavy if it mainly uses:
> ets:update_counter(Tab, Counter, {2, 0}).
>
> and i should set it to {read_concurrency, true}
>
> 3. both read/write heavy if:
> ets:update_counter(Tab, Counter, [ {2, 0}, {2, N, 0, 0} ]).
>
> and i should set it to {read_concurrency, true}, {write_concurrency, true}
>
> Am i right?
>
> /Frank
>
>
> Wed 25 nov. 2020 à 12:31, Frank Muller <frank.muller.erl@REDACTED> wrote
> :
>
>> Thanks a lot Jesper!
>>
>> I thought about using the new counter module, by I don’t know how many
>> counters I will have in my system. They are created dynamically
>>
>> /Frank
>>
>> wed 25 nov. 2020 à 11:33, Jesper Louis Andersen <
>> jesper.louis.andersen@REDACTED> wrote :
>>
>>> On Tue, Nov 24, 2020 at 8:33 PM Frank Muller <frank.muller.erl@REDACTED>
>>> wrote:
>>>
>>>> Question: how should i set my table?
>>>> 1. both concurrency set to true:
>>>> 2. only read concurrency set to true:
>>>> 3. only write concurrency set to true:
>>>>
>>>> Please explain why?
>>>>
>>>>
>>> 4. Use the 'counters' module.
>>>
>>> The caveat is that your counter set is of fixed arity and you have a way
>>> to look up an index. If both are true, they are likely to beat ETS in a
>>> measurement benchmark shootout because less locks will be taken on them.
>>> I'd measure your results.
>>>
>>> The answer depends on your read/write patterns for solutions 1-3. And
>>> the CPU architecture setup, mostly in core count. It's very likely you
>>> don't get a full answer by thinking about how the locking structures are
>>> built in isolation. General rules of thumb: If mostly read, go with 2. If
>>> mostly written, go with 3. If you flip i.e., have a short window in which
>>> you mostly write and then mostly read for a while, then another
>>> write-block, ..., then go with 1.
>>>
>>> --
>>> J.
>>>
>>

-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20201125/f577ee16/attachment.htm>