[erlang-questions] Internal compiler atoms

Albin Stigö albin.stigo@REDACTED
Fri Jul 28 09:33:21 CEST 2017


Interesting problem... not completely sure I understand it 100% then.
What do you mean by "list of forms". How large is your module?

I'm not sure why the compiler registers so many atoms but I guess it
has to do with the compiler's internal representation of your module.

I find "The BEAM book" to be a great resource when I run in to these
kinds of problems:


On Fri, Jul 28, 2017 at 9:22 AM, Håkan Mattsson <hawk.mattsson@REDACTED> wrote:
> You must have mis-understood what I wrote.
> It is not my program that generates all those atoms. They are generated
> internally by the compiler while it is compiling my program from forms. The
> atoms my program are using do already exist in the forms data structure.
> I am very well aware of the +t flag. But it is quite boring to set it to
> 100M just to be able to compile. As I do not understand why the compiler
> dynamically generates all these internal atoms I cannot predict how big the
> atom table needs to be. In my latest run the compiler actually generated 25M
> atoms (which is 25 times the default size of the atom table). It surprised
> me.
> Please, do not come up with further suggestions about avoiding explicit
> creation of atoms in general. My question was much more specific.
> /Håkan
> On Jul 28, 2017 08:43, "Albin Stigö" <albin.stigo@REDACTED> wrote:
> 1. Try to avoid dynamically creating new atoms.
> 2. But I need to! Goto rule 1.
> 3. Dynamic atoms are not safe for long running code. You will
> eventually exhaust the atom table and this will lead to subtle bugs.
> 4. If you really DO need to create dynamic atoms for a quick and dirty
> hack, keep in mind that atoms with a common prefix ie. foo_1, foo_2,
> foo_3 etc will lead worse performance because of how erlang compares
> atoms (some Erlang guru correct me if I'm wrong but this used to be
> the case).
> --Albin
> On Fri, Jul 28, 2017 at 8:23 AM, Valentin Micic <v@REDACTED>
> wrote:
>> Is this anything that can be disabled?
>> Say that there is, very soon you would be asking: why is there a limit on
>> a
>> number of atoms?
>> Instead, you should write a code that does not generate 700k atoms.
>> V/
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list