Tue Feb 1 11:09:03 CET 2005
Yes, of course it could be done with a new BIF, but currently there
is no cheaper way of doing it.
But this sounds like an odd special case to me, and we do not want
to encourage application programmers to dynamically create atoms.
If we add such a BIF, I am sure someone wants a BIF that creates
an atom consisting of a base atom and an integer string suffix.
Or, I might be wrong - this is not an odd special case - or you
have an application where performance in this operation is
essential. Is it an actual problem for you?
(Thomas Johnsson XA LN/EAB) writes:
> What I was driving at (sorry for not being clear):
> both the hashing and the comparison of atoms could presumably be done *without actually*
> (re)creating the concatenated atom (especially not using intermediate lists)?
> -- Thomas
> -----Original Message-----
> Sent: den 1 februari 2005 09:56
> Subject: Re: Concatenating atoms
> Looking up an atom name in the atom table is fast. It is a hash table.
> Creating the atom name to look for (creating the two parts and
> appending) is also rather fast. All those operations are BIFs.
> You will produce some garbage for the GC, - one cons cell (two
> machine words) per character in Atom1 and two per character in
> Atom2 (I guess), so it is hopefully not very much.
> (Thomas Johnsson XA LN/EAB) writes:
> > Yes, this performance issue occurs when the created atoms already exist in the atom table.
> > (If the newly created atoms don't exist previously the atom table will be filled up quickly,
> > in which case we will have a different problem!)
> > So it ought to be a fairly fast operation to check whether the concatenation of two atoms
> > exist already in the atom table?
> > -- Thomas
> > -----Original Message-----
> > From:
> > [mailto:]On Behalf Of Raimo Niskanen
> > Sent: den 1 februari 2005 08:59
> > To:
> > Subject: Re: Concatenating atoms
> > (Thomas Johnsson XA LN/EAB) writes:
> > > There appears to be no cheaper way to concatenate two atom than
> > >
> > > list_to_atom(atom_to_list(Atom1) ++ atom_to_list(Atom2))
> > >
> > > ... or have I missed something?
> > > -- Thomas
> > Nope.
> > You have to create a new atom that just happens to have a string
> > representation that is the concatenation of two other atoms
> > string representations in the runtime system.
> > All atoms have the same size; one machine word. It is like a unique
> > integer with a string representation. The entries in the atom
> > table may differ in size, but that is just one place in the
> > runtime system.
> > When you create an atom you have to first check that its string
> > representation does not already exist in the atom table and if
> > not create a new entry with a new unique integer.
> > The atom table has got a fixed max size, so creating atoms during
> > runtime is often not a good idea, unless it happens a limited
> > number of times. If creating new atoms with new different string
> > representations is a part of the normal application processing, the
> > atom table will be filled one day and the runtime system fails.
> > --
> > / Raimo Niskanen, Erlang/OTP, Ericsson AB
> / Raimo Niskanen, Erlang/OTP, Ericsson AB
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
More information about the erlang-questions