[erlang-questions] Nested match specifications?

[Ivan Carmenates García]

Hi Diego,

 

I think both functions are the same about performance, I think the questions
is of how to use it, I bet you will get the same result using the function
you like most while you reduce the complexity of the query by reducing calls
to other functions and the times you filter the data, and as last point
while more specific you come getting the data, using keys, or indexers in
the query.

 

It’s my placer to help, that’s why we are here I think.

 

Best, Ivan.

 

 

De: erlang-questions-bounces@REDACTED
[mailto:erlang-questions-bounces@REDACTED] En nombre de Diego Llarrull
Enviado el: martes, 05 de marzo de 2013 11:22
Para: erlang-questions@REDACTED
Asunto: Re: [erlang-questions] Nested match specifications?

 

Ivan, Patrik:

Thank you both for the swift replies! Both provided functions that yield the
desired results. The functions are: 

 (I) ets:match(table, {"Peter", [{"children", '$1'},'_'] }).
(Ivan's)
(II) ets:select(xxx,ets:fun2ms(fun({"Peter",[{"children",Data}|_]}) -> Data
end)).   (Patrick's)

(II) is effectively rendered to

ets:select(xxx,[{{"Peter",{"children",'$1'}},[],['$1']}])

which is pretty similar to Ivan's suggestion. My final question (and I so
promise) is: it appears to me that (I) performs better than (II) because of
the lack of need of a transformation function such as ets:fun2ms(). However,
I don't known for sure whether ets:match() outperforms ets:select() or not.
I'm about to run a series of tests on big datasets to check this, but I
imagine that there is already an answer to this question. 

Once again, thank you very much. 

Diego


El 05/03/13 11:34, Patrik Nyblom escribió:

Hi!
On 03/04/2013 08:58 PM, Diego Llarrull wrote:

Hello everyone, 

I would like to insert in an ETS table a tuple with the following type
signature: 

{string(), [{string(), [string()]}]}

As an example: 

{"Peter", [{"children", ["Bob", "Paul"]}, {"father", ["Mike"]}]}


My question is the following: is it possible to solve, using match
specifications, nested queries like "Retrieve the name of Peter's children"
?

That is, a query where I would need to 

a) Fetch all ("the", since its a set) tuples of size 3 where "Peter" is
located in the first position (doable with MS)
b) Let '$2' be the value in the second position of the tuple fetched in a).
Then, fetch the value corresponding to the key "children" in '$2', if
interpreted as a key-value list (i.e. lists:keyfind() should work on '$2'). 

If I understood correctly, lists:keyfind can't be used inside a match
specification because they only allow the BIFs described in
http://www.erlang.org/doc/apps/erts/match_spec.html. My question is: is
there any low-level mechanism to operate on lists inside match
specifications, or am I trying to push the boundaries of match
specifications?

Yes, you're trying to push the boundaries of match specifications :)

You'll have to do a lists:keysearch/keyfind on the results of the ets:select
(when you're back in proper Erlang code), only constant time BIF's can be
added to the ms language, so it's unfortunately not even an option to add
this particular function... Without a huge rewrite that is... 

So...
  [lists:keyfind("children",1,P) || P <-
ets:select(xxx,ets:fun2ms(fun({"Peter",Data}) -> Data end))].
would be the solution. Except of course if the list has a particular order,
or you instead use some record'ish data structure, so that you can match
directly:
  ets:select(xxx,ets:fun2ms(fun({"Peter",[{"children",Data}|_]}) -> Data
end)).
But looping over the list inside the ms is not possible.



In case anyone wonders "Why not use Query Lists Comprehensions?" the answer
is: "Because of performance issues: in our platform, we need to dynamically
build QLCs based on the number of arguments that arrive, which forces us to
build them as strings and then use qlc:string_to_handle() which is SLOW". 

Any help of insight will be greatly appreciated. Thank you very much in
advance. 

Diego Llarrull

  

Cheers,
/Patrik









_______________________________________________
erlang-questions mailing list
erlang-questions@REDACTED
http://erlang.org/mailman/listinfo/erlang-questions







_______________________________________________
erlang-questions mailing list
erlang-questions@REDACTED
http://erlang.org/mailman/listinfo/erlang-questions

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130305/de706085/attachment.htm>