[erlang-questions] Ets read concurrency tweak

[Chandru]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150514/9c43b652/attachment.htm>