[erlang-questions] Internal compiler atoms

[Håkan Mattsson]

See http://erlang.org/doc/man/compile.html#noenv_forms-2 about forms.

My module is quite  large. The compressed beam-file is about 45MB. But that
is besides the point. It does not explain why the atoms are generated.

/Håkan

On Fri, Jul 28, 2017 at 9:33 AM, Albin Stigö <albin.stigo@REDACTED> wrote:

> 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
> >>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170728/87eb84e3/attachment.htm>