Re: ETS table with only counters

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 <[email protected]> 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 <
> [email protected]> wrote :
>
>> On Tue, Nov 24, 2020 at 8:33 PM Frank Muller <[email protected]>
>> 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.
>>
>