[erlang-questions] ets vs list

[Morten Krogh]

> No, there are several other overheads. For instance, you must somehow
> implement a hash table from immutable dynamically typed data structures,
> whereas in ETS (in C), you can use mutable arrays. The dict module,
> for example, uses a tree structure of tuples. Once you've located
> the leaf tuple where the object is to reside, you have to create
> a new copy of that tuple, which means you must also update (copy)
> the parent tuple, etc.

But it is to some extent self imposed that you want a functional data 
structure.
You could have used the process dictionary for this or some foreign 
interface.
Nowadays nif, but that was not available to you then.

Why didn't you use the process dictionary? It is made for this situation.

Morten.




> Also, when traversing the tree, you cannot avoid the type checks
> ensuring that it's actually a tuple you're stepping into. In the
> case of C, you will not be performing runtime type checks on the
> hash space.
>
> OTOH, with SMP Erlang, you have to protect the ETS tables with
> mutexes, whereas on the process heap, you don't have to worry
> about contention.
>
>> 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.
> In the case I described, the task was to model the ETS API
> faithfully, which meant a separate process per table. This also
> included copying, as data sent in messages is copied from
> process to process. Otherwise, if you use dict, gb_trees, etc.
> or the process dictionary, you can avoid the copying and get
> quite good performance if the stored data structures are large.
>
>> So, if we compare ets with dict or the process dictionary, then ets
>> should perform really badly on large values, it seems.
> Yes. OTOH, the process dictionary is difficult to share...
>
>
> BR,
> Ulf W
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>