<div dir="ltr">2013/8/30 Garrett Smith <span dir="ltr"><<a href="mailto:g@rre.tt" target="_blank">g@rre.tt</a>></span><br><div class="gmail_extra"><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">
Alternatively, if your JSON is acting more as a lookup table -- strip<br>
off the one-tuple and use proplists:get_value - it's *very* efficient<br>
with small lists (based on rough measurements, < 200 items).<br></blockquote></div><br></div><div class="gmail_extra">I feel obliged to point out that for {Key,Value} lists, it usually makes better sense to use lists:keyfind/3 instead of functions from the proplists module. Performance-wise, because it's faster by a factor of 3x for small lists and 10-15x for lists of length 30+ (keyfind is implemented in C, and so is hard to beat). And arguably semantic-wise as well, because the proplists module don't work quite the way many believe (it's not just [{_,_}] it handles).<br>
<br></div><div class="gmail_extra">Whether that micro-benchmark difference has any impact on your system as a whole depends of course on how heavily it's used -- it did on one I worked on once --, but my view is that, all other things being equal, there's no reason to adopt proplists as a habit if it offers no other advantages over more lightweight functions.<br>
<br>(Assuming that 'dict' is the obvious alternative when dealing with lookup tables: My quick meaurements indicate  that proplists:get_value() becomes slower than dict:fetch() at 6 elements; for lists:keyfind() vs. dict that doesn't happen until ~140 elements. At which point proplists is 16x slower than both.)<br>
</div><div class="gmail_extra"><br>Just my 2¢ - no nitpicking at all, it's just that you brought up performance...<br>(in the same sentence as proplists)<br><br></div><div class="gmail_extra">/Erik [like pushing a button]<br>
</div></div>