[jhc] Atoms, Infos and unique ids.

[Lemmih]

On Fri, Feb 22, 2008 at 1:56 AM, John Meacham <john at repetae.net> wrote:
> 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.

Yes, sorry for not being clear. It's the pointers to atoms, and not
atoms themselv, that are causing trouble.

>  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.

I a fan of assigning locally unique ids as necessary since we already
do this on a per-function level.

-- 
Cheers,
 Lemmih