<br><div class="gmail_quote">On Mon, Mar 12, 2012 at 5:05 PM, Matthew Evans <span dir="ltr"><<a href="mailto:mattevans123@hotmail.com">mattevans123@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div><div dir="ltr">
Hi,<div><br></div><div>Many of my processes (gen_servers) need to store some kind of indexed data in the state record. Usually this involves creating a set/dict/ets table in the init/1 function, assigning it to an element in the state record and using the data on each handle_call/cast/info.</div>
<div><br></div><div>My usual strategy is anything that is 100% private to my gen_server and will contain less than 50 or so records I will use sets/gb_trees or similar. In all other cases I would use an ETS table.<span style="font-size:10pt">┬áIs there an official recommendation?</span></div>
<div><br></div><div>Thanks</div><div><br></div><div>Matt</div><div><br></div></div></div></blockquote><div><br>It depends a lot on your usage patterns. But for anything less than 50 to 100, I tend to simply use a proplist or keylist, as they "print" nicely in debugging situations. A set is good for when you need a set. The other data structures have characteristics that map well onto certain types of usage patterns. But my code hasn't so far needed anything more complicated. I view ets as a good stepping point to dets, if I know that I may want to persist stuff, I might opt for ets first. But even that has turned out to be premature optimisation.<br>
<br>It might be nice to have an overview summary of the various standard data structures with examples of when each of them is most appropriate.<br><br>But in summary, I'd recommend sticking with the simplest data structure, and only increase complexity if you find that you need it. I'm one of those people who have no fear of rewriting code over and over, though. So YMMV.<br>
<br>Robby<br><br></div></div>