Using an ets table for a gen_server state

Question

I am writing a gen_server which I want to hold an ets table as a state, then ets table was created somewhere else. How should I add this to the state of the gen_server?

I want to use the ets table rather than create a new dictionary for it because I want to save memory.

Also, How does one iterate through a ets table? I want to iterate or read each value in the table and check the value, then I want to do one of two options depending on the value.

Would it be easier just to turn the ets table into a list and traverse the list?

Thanks

Answer 1

Some suggestions:

• Read the ETS man page: erl -man ets

• An ETS table is identified either by its name (in the case of the named_table option) or by its table id. Pass that information to the gen_server and keep it in the state:

  -record(state, { ..., tbl = none }).
  
  
  init([TableID]) ->
      ...,
      {ok, #state { tbl = TableID }}.
  

ETS will perhaps not save that much memory. There is a new flag coming up for a later Erlang/OTP release where ETS tables can be compressed so their contents are compressed before storage and uncompressed upon reads (there is a computational overhead to this).

To iterate through an ETS table you have several options. ets:first/1 ets:next/2 is one such interface. ets:foldl/3 ets:foldr/3 another. ets:match/3 gives you a continuation (a cursor) to walk with. ets:select is even more general than match.

Would it be easier to turn it into a list? This depends. The power of an ETS table is that they have an option {keypos, N} defining a key on which elements are stored. ets:lookup(?TAB, Key) is extremely fast so you have fast lookups on keys. It is not so with lists. But on the other hand, if you always traverse all of the list it may be a simpler solution (as long as you don't pass the large list between processes).

Turning the whole table into a list and traversing it should perhaps be avoided. You will generate the list in memory and then traverse it which is expensive. It is way better to traverse it a bit at a time so the amount of live memory is low.