探讨了ETS（Erlang Term Storage）接口如何为Erlang进程提供非垃圾回收的数据存储，及其独特的并发特性。比较了使用ETS与纯Erlang实现的数据表在效率上的差异，特别是在单处理器版本中，所有ETS操作实际上由单一调度器进行序列化。
[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
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
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
