[erlang-questions] Concurrency Orientated Design question

[Marcel Meyer]

Haha, I was actually wondering if each node could be a process, but some
trees have 100,000's of nodes, so that didn't seem right?

By scenario 3 do you mean to store the hierarchical data as a flat list?
I've done some analysis on this, and even with graph optimization like
pre-ordered tree traversal, traversing the actual tree was still faster.
There are some business scenarios for example where access has been removed
for a user on a node, and access to lower down nodes have to be inferred, so
having it as a proper graph is handy.

On Mon, Feb 7, 2011 at 2:13 PM, Jesper Louis Andersen <
jesper.louis.andersen@REDACTED> wrote:

> On Mon, Feb 7, 2011 at 19:29, Marcel Meyer <marcel.meyer@REDACTED> wrote:
>
> > Scenario 2:
> > Spawn an "owner" tree processor, and on all "read-like" operations, spawn
> a
> > new process to deal with that request.
> > The good:
> > Better scaling
> > The bad:
> > Spawning a new process with the existing state might be expensive (ito
> > memory and time), as these trees could be large (4Mb max, usually <
> 200kb).
> > Updating the tree will become hairy, unless updates are only done by the
> > owner, like when you spawn an ets table as private.
>
> Scenario 3:
>
> The tree nodes are stored in ETS. Otherwise it is like scenario 2.
>
> Scenario 4:
>
> Each tree node is a process :)
> --
> J.
>