[erlang-questions] Why is there an atom table?

[Björn-Egil Dahlberg]

The key thing with atoms is that they are immediates. This means that the
atom term it self takes zero heap memory in an Erlang process.

Atoms are extremely efficient. A matching '=:=' operation, the normal thing
to do with atoms, only require a one word compare.

Atoms need to store the textual representation somewhere and this is where
the table comes in. The immediate term is an reference to this
representation. It is system wide shared to save memory of course.

When developer uses atoms as strings and not as "enums" they are still
space efficient but will require lookups to the atom table. Not a huge deal
but annoying.

To answer your question: Getting rid of the table and storing textual
representation in heap memory will increase memory consumption
dramatically. There are suggested comprises, one is
https://github.com/erlang/eep/blob/master/eeps/eep-0020.md for instance.

The one thing to remember: we want atoms to be *immediates* - it is an
extremely important feature.

// Björn-Egil



2013/7/20 Pierre Fenoll <pierrefenoll@REDACTED>

> Hi,
>
> So, atoms are stored in a shared table, using locks to read & write, and
> never garbage-collected.
> Well we know the issues that emerge from this.
>
> What I can't find on the Web is the purpose of this table.
> Why does Erlang needs to assign a unique hash to a <255-characters string
> and put it in memory?
>
> I thought atoms were just like enums, thus the only actions needed on them
> were ==, =:= and the various conversions to string or binary.
> An atom (approximately) corresponds to this regexp:
> [a-z'][a-zA-Z0-9_']{,254}.
> Its syntactic representation **already** supports the actions I cited.
>
> Why not get rid of the atom table and and just use strncmp(3)?
>
> Cheers,
> Pierre
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130720/e0f01ebb/attachment.htm>