[erlang-questions] Internal compiler atoms

[Albin Stigö]

Håkan,

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:
https://github.com/happi/theBeamBook


--Albin

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
>>
>
>