[erlang-questions] Ets read concurrency tweak

[Viacheslav V. Kovalev]

>> - Your two tests which use the read_concurrency option are both setting it to 'true' (lines 31 and 50 in the gist)
Ah yep, my fault. Shameful copypaste. However, as you noticed,
`{read_concurrency, false}` should be the same as first test with
default parameters. When I've fixed this, nothing was changed.

What about eprof - it is the last thing I've added to this test. With
or without profiler - same results (except of absolute values). Main
purpose of profiling was to see if `ets:lookup` is really most
expensive operation in this test (and this is true).

Also I've experimented with different sizes of table and different
sizes of keys in table. Seems all this things doesn't matter, so I am
really confused with this option and have no ideas.

2015-05-14 17:52 GMT+03:00 Chandru <chandrashekhar.mullaparthi@REDACTED>:
> Hi,
>
> A few comments.
>
> - Your two tests which use the read_concurrency option are both setting it
> to 'true' (lines 31 and 50 in the gist)
>
> - I wouldn't run profiling when trying to compare two different options. It
> could be that the overhead of profiling is masking any differences between
> the two use cases.
>
> - Setting {read_concurrency, false} is the same as not specifying it (so in
> effect 2 of the tests are the same)
>
> cheers
> Chandru
>
>
> On 14 May 2015 at 11:29, Viacheslav V. Kovalev <kovyl2404@REDACTED> wrote:
>>
>> Hi, List!
>>
>> I'm playing with ets tweaks and specifically with read_concurrency.
>> I've written simple test to measure how this tweak impacts on read
>> performance. Test implementations is here
>> https://gist.github.com/kovyl2404/826a51b27ba869527910
>>
>> Briefly, this test sequentially creates three [public, set] ets tables
>> with different read_concurrency options (without any tweaks, with
>> {read_concurrency, true} and with {read_concurrency, false}). After
>> one table created, test pupulates table with some random data and runs
>> N readers (N is power of 2 from 4 to 1024). Readers performs K random
>> reads and exists.
>>
>> Result is quite surprising for me. There absolutely no difference
>> between 3 these tests. I have run this test on Erlang 17 on 2-, 8-,
>> and 64-core machines and could not find any significant performance
>> impact from this tweak.
>>
>> Could anybody explain usecase of this tweak? What should I do to see
>> any difference and understand when to use this option?
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>