<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 26, 2016 at 4:39 PM, James Aimonetti <span dir="ltr"><<a href="mailto:james@2600hz.com" target="_blank">james@2600hz.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">we are using ets:delete(Tab, Key) for each Key found in the worker process<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The only other delete operation is to flush the whole table with ets:delete_all_objects/1.<br></blockquote><div><br></div><div>From what I can tell in the vm source neither ets:delete/2 or ets:delete_all_objects/1 should end up in a yield to ets:delete_trap/1. Only ets:select_delete/2 or ets:delete/1 take that code path.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
We haven't tried enabling the read/write concurrency flags yet; would<br>
write_concurrency make a difference when calling ets:delete/2? </blockquote><div><br></div><div>If you have multiple other processes doing reads/writes into the table at the same time as you are doing deletion in it, then yes it may help speed things up.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Any tips on profiling ETS usage and finding efficiencies?<br></blockquote><div><br></div><div>I would use tracing, either call_time or just plain ordinary call+return tracing together with timestamps to see if any suspect ets function take a long time to complete and then from there try to figure out why.</div><div><br></div><div>Lukas</div></div></div></div>