[erlang-questions] Ets read concurrency tweak

[Sergej Jurecko]

I think read_concurrency/write_concurrency are about mutexes between schedulers. So if you have 1000 processes on a single scheduler it makes no difference. How many logical cpus did the machine you were executing tests have?


Sergej

On 14 May 2015, at 17:50, Viacheslav V. Kovalev <kovyl2404@REDACTED> wrote:

>>> - 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
>> 
>> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions