[erlang-questions] ets vs list
Mon Sep 13 19:11:46 CEST 2010
Thanks. I just tried in the shell and saw that there were no new
processes after creating an ETS table. fine.
Surely, you could model ets with a process and message passing. Why
should it be slower? The only overhead should be the message passing.
So, I guess your benchmark might depend on the size of the key/value
pairs. For large values, the performance should be the same, for small
values the process might be a bit slower.
So, if we compare ets with dict or the process dictionary, then ets
should perform really badly on large values, it seems.
Suppose we have a giant list, that we store in the tables with some key,
i.e, store(key) = [..,..,,,...............................]
If we want to traverse that list, dict and pd would start immediately,
whereas the list from ets would have to be copied before traversing
And after reading the list from ets it would have to be freed at the
next garbage collection, where as the dict and pd didn't generate any
On 9/13/10 6:25 PM, Ulf Wiger wrote:
> On 09/13/2010 06:10 PM, Morten Krogh wrote:
>> Thanks again.
>> My question might have been hard to understand because I made an
>> assumption that might be wrong, namely that
>> an ets table has a corresponding process. I don't mean the owning
>> process, but an implicit process that is spawned automatically
>> when the table is created, and that all insertions and deletions are
>> going through that process. Is that just my imagination?
>> Is an ets table only a hash table and nothing more? No corresponding
>> process that serializes all access to it? ETS:lookup is just a function
>> call, not a hidden
>> message pass, receive construct or what?
> ETS tables do not have a corresponding process (except for the
> temporary pseudo process during select()). Serialization is done
> with mutexes, so essentially, it's just a hash table or B-tree.
> That said, Erlang purists often hide behind the fact that you
> _could_ model ETS tables with processes and message passing
> (thus, process spawning and messaging are still the only
> means of side-effecting in Erlang ;-)
> It's not terribly difficult, but hard to do efficiently. The
> main issue is named tables, since you need a table registry,
> which implies another set of messages. I did this once (and
> as it happened, Robert V was doing the same thing at the same
> time - I was doing it for the Erlang Processor, and he was
> doing it for his own VM, VEE). As far as I recall, performance
> of my ETS emulation was ca 30x slower than regular ETS, at
> least on named tables*. :) This was many years ago, so the
> numbers may be completely different today.
> Ulf W
> * But, as it happened, the Erlang Processor used ca 30x fewer
> clock cycles than my workstation to execute Erlang code, so
> ultimately I thought myself no worse off. :)
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:
More information about the erlang-questions