[erlang-questions] Internal compiler atoms
Fri Jul 28 15:16:07 CEST 2017
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.
On Fri, Jul 28, 2017 at 9:33 AM, Albin Stigö <albin.stigo@REDACTED> wrote:
> 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>
> > 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.
> > 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
> > atom table needs to be. In my latest run the compiler actually generated
> > atoms (which is 25 times the default size of the atom table). It
> > 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
> >> 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...
More information about the erlang-questions