Concatenating atoms
Joe Armstrong (AL/EAB)
joe.armstrong@REDACTED
Thu Feb 3 12:12:18 CET 2005
> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of Thomas Lindgren
> Sent: den 2 februari 2005 12:22
> To: erlang-questions@REDACTED
> Subject: RE: Concatenating atoms
>
>
>
> --- "Joe Armstrong (AL/EAB)"
> <joe.armstrong@REDACTED> wrote:
>
> > 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
> > efficient code.
>
> I started out with looking at the details of your
> estimate (is it speedup or cycles?) but I think the
> core issue is really another one.
>
> First: I fully support not running out of atoms -- I
> hardly would have asked for atom GC if I didn't. I
> think it's an implementation flaw to have to worry
> about such a thing.
>
> Second: Whether the proper method of managing atoms is
> atom GC, per-module atom tables with a new data
> representation, or something else, is an engineering
> issue. If your formula above indicates success,
> implement your proposal and see if it was right.
>
Absolutely - I have no idea which approach is best.
I have a "gut feeling" that a true 64 bit erlang
with two forms of atoms would be best
Short atoms (10 packed characters) which fit into a single
and Long atoms in a local module table with a cached hint
pointer.
Unfortunately (as Björn pointed out) this is not a minor
change - this is a pretty bit re-write before you get to
know the answer.
/Joe
> Best,
> Thomas
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - You care about security. So do we.
> http://promotions.yahoo.com/new_mail
>
More information about the erlang-questions
mailing list