yes of course, i was just measuring worst case across both.<div><br></div><div>@Ulf good point.</div><div><br></div><div>Will take suggestions and try a few other tests.</div><div><br></div><div>-AD<br><br><div class="gmail_quote">
On Thu, May 3, 2012 at 1:38 AM, dmitry kolesnikov <span dir="ltr"><<a href="mailto:dmkolesnikov@gmail.com" target="_blank">dmkolesnikov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
In your test script select does a full table scan, emulates foldl. But<br>
your use-case is foldl through subset. Should you measure performance<br>
of that case?<br>
<br>
Best Regards,<br>
Dmitry >-|-|-*><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 3.5.2012, at 7.57, Ulf Wiger <<a href="mailto:ulf@feuerlabs.com">ulf@feuerlabs.com</a>> wrote:<br>
<br>
> 3 maj 2012 kl. 05:35 skrev AD <<a href="mailto:straightflush@gmail.com">straightflush@gmail.com</a>>:<br>
><br>
>> gproc seems to use an ordered_set ETS table and then an ets:select() to match against the keys it needs.  I did some basic tests with a 5 million row ETS ordered set table and ets:foldl still seems to come out faster.<br>

><br>
><br>
> The key to good select() performance in an ordered_set table is to ensure that the first part of the key pattern is bound. In your test, the key pattern was a free variable, forcing the match spec evaluator to test every single record in the table.<br>

><br>
> Gproc strives to do 'bounded selects' as much as possible.<br>
><br>
> BR,<br>
> Ulf W<br>
><br>
> Ulf Wiger, Feuerlabs, Inc.<br>
> <a href="http://www.feuerlabs.com" target="_blank">http://www.feuerlabs.com</a><br>
</div></div></blockquote></div><br></div>