atoms vs. integers

[Shawn Pearce]

Lennart ?hman <lennart.ohman@REDACTED> wrote:
> Hi!
> (a lot cut away... :-)
> > ...
> >What about sending these over the wire then in distributed messages to
> >other nodes?  I'm going to use Erlang distribution rather than UBF or
> > ...
> 
> Try doing term_to_binary/1 on what you intend to send and you'll see what
> you are really sending.

Thanks, that gave me what I knew it would give me.  An ei formatted
message wherein the atom is a string.  :-)  Meanwhile the normal ints
1 and 2 were formatted as <<131,97,1>> and <<131,97,2>>, that is, two
bytes to transfer the one very tiny int.  Atoms seem to have at least
a header of 3 bytes, followed by the characters that make up the atom.
(That 3 byte header is excluding the 131 ei version marker.)

I'm going to use macros, and decide this later.  I think its stupid
to use ints here, this is why Erlang has atoms - but from a performance
point of view, I'd be using just 1 bit in C.  :-)  I think its in the
critical loop as far as communication goes, enough to possibly justify
the more difficult to debug 1/2 vs. atoms 'finished'/'not_finished'.

> >...
> >On a related note, how do bigints compare to just using a tuple of
> >small ints or a binary?  I'm thinking about both term storage and
> > ...
> 
> http://www.erlang.org/doc/r9c/doc/efficiency_guide/part_frame.html
> 
> Integer (big numbers) 	3..N words
> Tuple 	2 words + the size of each element

Thanks, I had forgotten about this table.  Looks like they would be the
same size for the same 96 bits of storage.  It'd be better off with
the bigint then, as its ordering semantics would be more 'natural' for
someone else to understand, than the concept of ordering tuples...
(Despite the fact that tuples can in fact be ordered!)

-- 
Shawn.