[erlang-questions] Processes stuck in ets:select_trap
Jesper Louis Andersen
jesper.louis.andersen@REDACTED
Mon Oct 26 13:50:27 CET 2015
It depends on how your filter function works:
Create a table:
2> ets:new(foo, [named_table, {keypos, 1}]).
foo
Fill the table so we can measure lookup differences in time:
3> ets:insert(foo, [{K, K+1} || K <- lists:seq(1, 1000000)]).
true
Create a point-query match spec:
4> MS = ets:fun2ms(fun({3, V}) -> V end).
[{{3,'$1'},[],['$1']}]
Run a query with this matchspec:
5> timer:tc(fun() -> ets:select(foo, MS) end).
{25,[4]}
Create another match-spec where you don't match directly on the key:
6> MS2 = ets:fun2ms(fun({K, V}) when K == 3 -> V end).
[{{'$1','$2'},[{'==','$1',3}],['$2']}]
Now time this one:
7> timer:tc(fun() -> ets:select(foo, MS2) end).
{177663,[4]}
As you can see, the MS2 variant requests elements of the form {$1, $2} and
then proceeds to filter them via $1 == 3, which is much more expensive than
the first one which requests data of the form {3, $2} and then needs no
filtering.
On Mon, Oct 26, 2015 at 1:40 PM, Max Lapshin <max.lapshin@REDACTED> wrote:
> Correct me if I'm wrong, but ets:select is always a full table scan.
>
>
--
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151026/35c24547/attachment.htm>
More information about the erlang-questions
mailing list