[erlang-questions] Can gen_tcp/inets store connection-specific user state?

Jesper Louis Andersen jesper.louis.andersen@REDACTED
Tue Jul 20 18:55:13 CEST 2010


On Tue, Jul 20, 2010 at 6:46 PM, Tony Arcieri <tony.arcieri@REDACTED> wrote:

> I'm afraid you're the one who will have to enlighten me here.
>
> My understanding is that ETS are implemented as Judy tables, which I know
> very little about and sound rather complicated.  I can't find specific
> details about the algorithmic complexity of Judy lookup, except one
> reference to it being worse case O(log_256 n).  Are you suggesting it
> is amortized O(1) or something?

O(log_256 n) is probably O(1) for most practical purposes. I am not
sure the VM uses Judy-arrays. The idea in the Judy-system is to beat
the real problem in modern CPU architectures: Memory bandwidth. Clock
cycles are "practically free" now. The question is how much data you
have to load. Judy-arrays provides a compact memory representation
which is then unpacked while in the CPU registers, trading memory
bandwidth for CPU cycles. In fact Judy has several possible
representations of an node in its tree-structure and can change
between them to ensure a good memory bandwidth usage.

Personally, I would pick ETS. It is a a rather simple start and it is
about the only thing we have in erlang when you want something
array-like or fast access.
> Round tripping the state end-to-end ensures it never needs to be placed in
> any kind of associative data structure and precludes the issue entirely.
>  However, as you mentioned, yes it would seem that there would be a degree
> of copying involved, or rather the construction of new terms which
> delivering the gen_tcp messages has to do anyway.
>
> It's sounding to me like a proxy process is probably the best way to go.
>  This at least lets me link the proxy to the controlling process of a
> particular socket, so I don't have to worry about "garbage collecting" the
> ports/socket objects from an ets table.
>
> --
> Tony Arcieri
> Medioh! A Kudelski Brand
>



-- 
J.


More information about the erlang-questions mailing list