Thomas Johnsson XA (LN/EAB)
Tue Feb 1 10:10:52 CET 2005
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)?
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-----
> [mailto:]On Behalf Of Raimo Niskanen
> Sent: den 1 februari 2005 08:59
> 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
> 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
More information about the erlang-questions