Getting concurrency

Ulf Wiger (AL/EAB) <>
Tue Jun 14 15:25:07 CEST 2005



Vlad wrote:
> [ In my experience, ets and mnesia tend to appear because 
> there are no other mutable data structures in Erlang, which 
> is an artifact of the language design, not of the 
> concurrency model. ]

Actually, the ets API can be fully emulated with an Erlang
implementation -- essentially spawning a process for each
ets table. I did it once for the ECOMP (Erlang Processor),
and on a regular workstation, it was about 30x slower than 
built-in ETS. Robert Virding wrote his own erlang-based ETS
at the same time. We compared notes for a while. My implementation
was more beautiful than his, but his was slightly faster. ;-)

There were some unfortunate API decisions in ETS that caused most of 
the performance penalty... or mainly only one: ets tables can be 
"registered", but they don't share namespaces with processes
(i.e. you can have a process and an ets table "registered" under
the same name.) Furthermore, you can have private named tables.
This makes it pretty much impossible to fully emulate an ets
table with a process -- you have to put a name server process
in there in order to find the process holding the table.

Ignoring named tables, the performance difference between built-in
ets and erlang-based ets is quite small. Semantically, there are 
no show stoppers.

/Uffe



More information about the erlang-questions mailing list