ErlCee++

[Shawn Pearce]

Actually I think beam supports a single heap system now.  Its a
compile time ./configure flag, but it gives you a single large heap.
Messages are just (more or less) pointers at that point.  But odd
thing is the single heap can run slower in some cases.

Large binaries are also shared, pointers are just copied to the target
process.  So if you can use bit syntax and are working with binary
data it can work to keep a large amount of data in a binary or two.

ets works well for sharing data, but the data must be copied into the
receiver process.  If you are doing a lot of lookups this can be
slow.


Cedric Shock <cedricpublic@REDACTED> wrote:
> >Of course, we're now starting the debate about why messaging and private
> >heap data in a concurrent environment is a better way to develop than
> >the lets-share-everything-and-pray method used by most pthread
> >programmers.
> >
> 
> This is something I've wondered about. If we don't have destructive 
> assignment, then it should be possible to share a chunk of memory across 
> a message, so that data that is mostly unchanged can be shared in common 
> between processes with less risk. I assume this isn't done because of 
> the difficulty in handling two different message passing systems for 
> local and remote processes, and added complications in the garbage 
> collection. It would be interesting to be able to share inmutable data 
> structures between processes.
> 
> I just realized there is no need for this (or it has little aditional 
> utility), as erlang term storage accomplishes essentialy the same thing.
> 
> --Cedric
> 

-- 
Shawn.

  Sacred cows make great hamburgers.