<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">On Tue, Jan 18, 2022 at 8:46 AM Frank Muller <<a href="mailto:frank.muller.erl@gmail.com">frank.muller.erl@gmail.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hi Mikael,</div><div dir="auto"><br></div><div dir="auto">I ┬átried them all before posting here.</div><div dir="auto"><br></div><div dir="auto">From fastest to slowest:</div><div dir="auto">1. select/2 (stable numbers)</div><div dir="auto"><span style="border-color:rgb(0,0,0);color:rgb(0,0,0)">2. match_object/2</span></div><div dir="auto">3. first/1 + next/2</div><div dir="auto">4. tab2list</div><div dir="auto"><br></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">You also need to consider memory usage. When you copy a potentially large ETS table into the heap of a process, you risk blowing up if the table is large. I'd probably safe_fixtable/2 on the table, traverse it with match_object/3 1000 elems at a time or so, then remove the fix when $end_of_table is reached. If any kind of disk I/O is involved, you are likely to be I/O bound on the disk anyway, or your serialization scheme is what is going to slow you down. But because of the table fix, you should be able to work on the disk set in a stable manner.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Clearly, there's some consideration w.r.t if the serialization has to "stop the world" until the table is on disk. Working around that would be my main concern.</div><br></div></div></div>