Atomic ets

[Ulf Wiger (AL/EAB)]

> -----Original Message-----
> From: owner-erlang-questions@REDACTED 
> [mailto:owner-erlang-questions@REDACTED] On Behalf Of Matthias Lang
> Sent: den 20 december 2005 09:15
> To: Robert Raschke
> Cc: erlang-questions@REDACTED
> Subject: Re: Atomic ets
> 
> Robert Raschke writes:
> 
>  > If your application uses ets as a communication mechanism 
> between  > processes, that is surely quite a sore design mistake.

Note the wording "ets as a communication mechanism"

> Looking at a freshly started erlang node, I can see a number of ETS
> tables:
> 
>    1> ets:all().               
>    [ac_tab,
>     inet_db,
>     inet_hosts,
>     file_io_servers,
>     inet_cache,
>     global_names_ext,
>     global_locks,
>     global_names,
>     10,
>     9]

I have a fair idea of what most of these do, and 
I don't think any of them use ets as a communication
mechanism, but rather as an internal storage structure.


> In some (many? most?) cases, ETS seems to have been used for 
> no particularly good reason at all. For example: inet_db is a 
> gen_server which uses an ets table (inet_db) to
> store its 20 configuration/environment parameters.

I couldn't say what the scaling potential of inet_db
is. Can you? BTW, 20 items used to be roughly the 
break-even point between a list and ets. After that,
ets was superior for random access.

> The only explanation I can think of is "it must be
> historical junk". Or am I missing something?

It's probably mainly historical, since dict, gb_trees,
etc didn't always exist. But also, choosing ets is 
convenient - and you know it's going to scale up
towards massive amounts of data (remember, the GC didn't
use to be that great with large process heaps...)

It's not always obviously better to use a functional
data structure, since you get the hassle of carrying
it around all the time + handling repeated updates of
a functional structure easily gets you into numbered
variables (X1 = ..., X2 = ..., .... X11=...),
which are a pain to keep track of, and can lead to 
very subtle bugs.

Having said this, I tend to use functional data
structures as much as I can nowadays. I think it's 
usually worth it, and after a while, I think you
learn how to program around the most common
pitfalls.

Perhaps we should have a tutorial on how to best
use functional data structures?

/Uffe