<div dir="auto">I’m only interested in ETS tables of type “set” and their performances/limits. </div><div dir="auto"><br></div><div dir="auto">/Frank</div><div dir="auto"><br></div><div><<a href="mailto:sverker@erlang.org">sverker@erlang.org</a>> wrote<br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On sön, 2018-09-02 at 01:29 +0200, Valentin Micic wrote:<br>
> There is a good chance that performance degradation you are referring to may<br>
> *not* be related to a "heavier concurrency" as much as it may be caused by a<br>
> rate of inserts into a table of type "ordered_set". The manual indicates that<br>
> ordered_set tables do behave differently "in come situations" (which I read as<br>
> "insert operations when a table gets big").<br>
> <br>
<br>
The paragraph containing "different behavior in some situations" is about the<br>
semantic differences for ordered_set due to keys compared with arithmetic ==<br>
instead of matching =:= as the other table types.<br>
<br>
<br>
Performance wise ordered_set use AVL trees with O(log N) for<br>
lookup/insert/delete while the others use linear hashing with O(1).<br>
<br>
ordered_set does also not implement option 'write_concurrency'. Every mutating<br>
operation on an ordered_set will seize exclusive write lock on the entire table.<br>
This will most probably improve as we are expecting a very exciting pull request<br>
in a near future implementing 'write_concurrency' for ordered_set.<br>
<br>
<br>
/Sverker, Erlang/OTP @ Ericsson<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div></div>