Concatenating atoms

[Thomas Lindgren]

--- "Joe Armstrong (AL/EAB)"
<joe.armstrong@REDACTED> wrote:

> > > There should not be a global
> > > atom table in the
> > > first place - it violates the principle of
> > > isolation.
> > 
> > Violates it in what way?
> 
> Things are isolated if they do not share anything.
> 
> Modules (after loading) share pointers into hash
> tables
> Which is *evil* 

Heh, well, erts is probably best viewed as Mordor in
that case :-)

Though to get "isolation" right, your two processes
are already running distributed Erlang on two
geographically separated PCs communicating over
wireless, and hence won't be sharing an atom table
anyway :-)

>   I'm not even sure if having an atom table etc.
> saves much time.
> Suppose we did atom comparisons the hard way,
> testing *each* time
> that the data in the atoms was identical how long
> would this take?

Easy enough to guesstimate, I suppose: how often do
you match atoms vs atoms? What is the new and old cost
of comparison, in cycles? How many new atoms are
allocated during execution? What is the cost of
allocating an atom (new vs old)? How many total cycles
does the old scheme require? 

Putting it all together means the new scheme will need
New_cycles = Old_cycles + AtomCompares*(New1-Old1) +
AtomCreations*(New2-Old2). Speedup is
Old_cycles/New_cycles. Presto! 

(At least as an approximation; the extra memory
operations may mess things up.)

Well, as long as the atom API/expected behaviour
remains the same (or, more to the point, better), I
certainly won't oppose your idea on principle. Rather,
it's an implementation trade off.

Best,
Thomas



		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com