<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 13, 2016 at 11:31 AM, Constantin Kulikov <span dir="ltr"><<a href="mailto:zxnotdead@gmail.com" target="_blank">zxnotdead@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just to clarify, are objects copied when we put/get them from an ets table?</blockquote></div><br></div><div class="gmail_extra">Yes.<br><br></div><div class="gmail_extra">Consider they were not. We have an object X in the table.<br><br></div><div class="gmail_extra">Process P1 gets X<br></div><div class="gmail_extra">Process P2 updates X to X' in the ETS table.<br><br></div><div class="gmail_extra">Now, according to immutability, P1's X should still be the same, but a reference to the object is X' in the table now, and thus P1 reads X' instead, breaking immutability of process P1.<br><br></div><div class="gmail_extra">The next case is even funnier:<br><br></div><div class="gmail_extra">P1 gets X<br></div><div class="gmail_extra">P1 sends X to P3<br></div><div class="gmail_extra">P2 updates X to X'<br><br></div><div class="gmail_extra">Note that P3 is one a different node in the cluster. This has to work seamlessly in Erlang, or you are in deep trouble. In other words, we are looking at a situation where you have to implement some copy-on-write scheme underneath in order to make things look like they do today. It may be possible, but one has to evaluate the implementation complexity over the efficiency gain. Copying will actually be faster in many cases on modern CPUs because it implicitly breaks cache conflicts.<br><br></div><div class="gmail_extra">In many cases, the trick with ETS is:<br><br></div><div class="gmail_extra">* Not storing large objects. Break them apart, so you can request subparts<br></div><div class="gmail_extra">* Fetch objects once, and subscribe to changes on objects<br></div><div class="gmail_extra">* Limit copying with ets:lookup_element/3 so you only copy over relevant parts of a tuple. "copying" an integer is mostly just a register transfer for instance.<br><br></div><div class="gmail_extra">Another thing you may want to care about is latency. If you equip your own tuple space with a GC, as in NEURAL, you have to account for the latency when GC occurs. ETS is specifically built for the case where such a GC latency is unacceptable. This means it is fair to make a trade-off where lookup latency is worse but predictable, but there will be *no* garbage collections at all.<br></div><div class="gmail_extra"><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">J.</div>
</div></div>