Concatenating atoms

[Raimo Niskanen]

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.xa.johnsson@REDACTED (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: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of Raimo Niskanen
> Sent: den 1 februari 2005 08:59
> To: erlang-questions@REDACTED
> Subject: Re: Concatenating atoms
> 
> 
> thomas.xa.johnsson@REDACTED (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