<div dir="ltr">Naturally, measure first.<div>Implement both methods. Switching from one to the other is trivial anyway.</div><div><br></div><div>For a hashtable store that is read-mostly I would suggest you use the process dictionary instead of ETS.</div>

<div>I have measured a 100x speedup compared to ETS (details and implementation here [1]).</div><div>Though you have to be careful with your writes as proc.dict. is a mutable datastructure. You might be interested in reading this [2].</div>

<div><br></div><div>[1]: <a href="https://bitbucket.org/fenollp/tmln-google/src">https://bitbucket.org/fenollp/tmln-google/src</a></div><div>[2]: <a href="http://ferd.ca/on-the-use-of-the-process-dictionary-in-erlang.html">http://ferd.ca/on-the-use-of-the-process-dictionary-in-erlang.html</a></div>

<div class="gmail_extra"><div><div dir="ltr"><div><div><br></div><div>Cheers,</div><div>-- </div><div>Pierre Fenoll</div></div><div><br></div></div></div>
<br><br><div class="gmail_quote">On 10 July 2014 22:56, zxq9 <span dir="ltr"><<a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5">On Thursday 10 July 2014 14:29:42 Derek Brown wrote:<br>
> Let's say you want to store on the order of tens of thousands key/value<br>
> pairs, with integer keys and proplist values (less than 10 simple key/value<br>
> pairs per proplist). Read-heavy with few writes.<br>
><br>
> What factors would you consider when going with a dict or an ETS table, or<br>
> perhaps something else?<br>
<br>
</div></div>Factors to consider? Whatever benchmarking both cases tells me. I would run<br>
each test case alongside a few different workloads on the same machine to<br>
figure out what good/bad things to expect from each approach.<br>
<br>
Someone will probably come along who actually has done this both ways and tell<br>
you there is indeed a Right Way, but usually I've found that taking the time<br>
to run some informal benchmarks provides more insight (which winds up useful<br>
elsewhere) than adherence to advice/data structure guidelines. Also, data<br>
structure advice often turns out to be a wordy version of "it depends..." and<br>
then a request for more information about the higher level problem you're<br>
actually trying to solve.<br>
<br>
What is the overall effect you're trying to achieve? It would be helpful to<br>
spell out the problem you're trying to solve (at the higher level like "how to<br>
best store 100k player's stats at once" instead of at the implementation<br>
detail of "is a dict or an ETS table better for 100k values?"). Very often<br>
you'll find someone has already tackled something similar and can give you<br>
some good advice you'd never get when asking just about the details of data<br>
structures. This prevents X->Y problem discussions.<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br></div></div>