Joe Armstrong (AL/EAB)
Wed Feb 2 09:10:13 CET 2005
> Thomas Lindgren
> Sent: den 1 februari 2005 16:56
> To: erlang-questions@REDACTED
> Subject: RE: Concatenating atoms
> > I'm not even sure if having an atom table etc.
> > saves much time.
> > Suppose we did atom comparisons the hard way,
> > testing *each* time
> > that the data in the atoms was identical how long
> > would this take?
> Easy enough to guesstimate, I suppose: how often do
> you match atoms vs atoms? What is the new and old cost
> of comparison, in cycles? How many new atoms are
> allocated during execution? What is the cost of
> allocating an atom (new vs old)? How many total cycles
> does the old scheme require?
> Putting it all together means the new scheme will need
> New_cycles = Old_cycles + AtomCompares*(New1-Old1) +
> AtomCreations*(New2-Old2). Speedup is
> Old_cycles/New_cycles. Presto!
Speedup = (... above ...) - cycles to do GC
+/- cycles to handle page faults
+ cycles spent while system was down because it
crashed because the atom table was filled
+ Speedups gained because I can write more
The last factor is important - why.
Because I *know* that the atom table is not garbaged I *avoid*
code that create atoms. Thus, for example, my XML parser represents the <tag>'s as
strings and NOT atoms.
This means that all my XML application have to written in a deliberately
inefficient manner (for the sake of correctness) - if there were atom table
GC OR no GC at all then I could change my parser to reprent tags as atoms, which
is obviously "The right thing to do" (TM)
(A one line change - since the code is thoughtfully provisioned for this eventuality)
> (At least as an approximation; the extra memory
> operations may mess things up.)
> Well, as long as the atom API/expected behaviour
> remains the same (or, more to the point, better), I
> certainly won't oppose your idea on principle. Rather,
> it's an implementation trade off.
> Do you Yahoo!?
> The all-new My Yahoo! - Get yours free!
More information about the erlang-questions