[jhc] Atoms, Infos and unique ids.

[John Meacham]

On Fri, Feb 22, 2008 at 01:34:32AM +0100, Lemmih wrote:
> >  Hmm... are you sure it would be faster? perhaps I don't fully understand
> >  what you want to do, but Atoms were darn fast when I was benchmarking, I
> >  could have broken them though. I mean, perhaps the speed benefit isn't
> >  that useful for jhc... I use the same atom implementation in C projects
> >  but I enjoy that in haskell-land I can hide the implementation behind a
> >  newtype to make them fully safe. I heart haskell.
> 
> The problem is not atoms per se; it's generating ids from a global
> store. When saving TVr's with associated names, the atom has to be
> saved instead of just the id. Duplicating few strings may not sound
> too serious but it does take its toll. It is relatively minor (but
> still significant) when compiling base-1.0.hl (7% cpu, 8% memory
> usage). However, it is dominating when compiling smaller pieces of
> code such as HelloWorld.

Oh, yes. I agree this needs to be fixed. but it seems orthogonal to the
issue of using atoms in the first place, as in. Any solution that works
for something that uses 'String' will work for 'Atom' and vice versa.

Something to try might be to rename everything other than top level
names to numeric ids right before writing out the ho file. Top level
names need to be globally unique, across time and space, as in, things
will break if two independent modules chose the same top level name for
something and then imported each other, but presumably by the time you
write out the ho you have lambda lifted most stuff out and the debugging
value of preserving them is less.

Though, you have not converted things to supercombinators which will
introduce more global names. (I actually should look into whether doing
this before writing ho files is useful).

In any case. it might be a simple thing to test out.

Otherwise I think the idea of a Binary type that maintains an
environment would be good, as we might find other uses for it besides
jhc identifiers.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈