ets为什么要设计成 内容不参与GC

[color=blue]原来所有的特性设计都是个妥协的过程哦。。。[/color]

Den 2006-12-23 01:16:34 skrev Yariv Sadan <>:

> This is all very interesting to me because the ets interface makes it
> seem as if an ets table is basically a dict hidden behind a
> gen_server, but ets actually has unique concurrency characteristics
> that can't be implemented in pure Erlang.

Well, they _can_, but it's not going to be nearly as efficient.
The difference will be reduced with SMP, since locking will
be required for ets. In the non-SMP version, no locking is
required, since all ets operations are in fact serialized by
the single scheduler.

To further close the gap, one can abstain from using named
public tables. In order to implement named public tables
in a pure erlang version, you either have to add a name
server, or come up with a naming scheme that maps ets
names to process names, and build atoms at runtime, or
have one single process that holds all tables (and keeps
a dictionary mapping names to table ids. The last option
will cause a terrible GC problem if there are lots of
large tables.

[color=red]For an anonymous table, a gen_server using dict is not much
worse than ets, except in certain situations. For example
if you build a table very quickly, the table server will
cause very rapid memory growth due to the copying GC. This
doesn't happen with the native ets implementation, since
there is no GC of ets objects. Also, if lots of data keeps
changing in the table, GC will be a problem since much of
the table will always be scanned. If the table is mostly
static, the majority of the data will end up on the
"old_heap" and not be scanned very often.

One could say that whole tables are GC:d, though, since
they are automatically removed when the owner process dies.
What all this boils down to is that one of the main
benefits of ets is that it provides non-GC:d data storage
for Erlang processes.[/color]

BR,
Ulf W
--
Ulf Wiger