[erlang-questions] trouble with erlang or erlang is a ghetto

Robert Virding robert.virding@REDACTED
Thu Jul 28 13:33:23 CEST 2011


On 28/07/2011 12:37, Jesper Louis Andersen wrote:
> On Thu, Jul 28, 2011 at 04:28, Jon Watte<jwatte@REDACTED>  wrote:
>
>> All modern languages have a simple hash map class that is efficient and
>> built-into the language. JavaScript, Python, Ruby, etc.
>> In Erlang, we have dict, and gb_tree, and proplist, and ets, but none of
>> them are as easy to use, and some of them have performance problems once you
>> scale over a few dozen or a few hundred elements, and others (ets) are way
>> overkill for this particular use case.
>>
>> Or would anyone want to argue that "dict" is actually as good/productive as
>> JavaScript objects or Python dicts?
> JavaScript, Python, Ruby, etc almost all have ephemeral dict
> structures. In Erlang, the structure must be persistent, like in
> Clojure/Haskell and so on. This rules out a number of possible
> structures.
>
> As it stands, "dict" is probably the right replacement, with gb_trees
> for some situations as they have different speed in those. The "dict"
> does fairly well, but it is implemented in Erlang and fast as it is,
> it cannot compete with a C-implementation of a ephemeral structure.
>
> Should we want to BIF/NIFify such a structure, I'd recommend either a
> patricia hash table or a HAMT. In fact, that would be an interesting
> thing to try. Though I wonder how much I can alter the in-memory
> structure of the tree from Erlang terms - I'd really like some cache
> efficient packing there for tree nodes.
dict uses linear hashing (as does ets) to make sure that there are no 
long pauses to interrupt the interactivity of the system. This would 
definitely be more efficient if it were to be done in C in a NIF. 
Unfortunately you would still have to copy parts of the tree when doing 
updates to preserve the immutability property of erlang data. Or use a 
smart way of doing destructive updates and keeping change lists.

Robert

-- 
Robert Virding, Erlang Solutions Ltd.




More information about the erlang-questions mailing list