On 7 July 2011 08:53, Simon Marlow <[email protected]> wrote: > Great - that should speed up linking too.
Here is another idea which should be worth a lot. The observation is that top level statically allocated _closure exports are rarely used. GHC exports 32,484 _closure pointers but only 5,214 distinct closures actually get referenced, so 27,210 are unused (I'm counting references reported by nm from object file making up ghc.exe and libHSghc). There are 19,233 closure use sites, with the closures being used having a "long tail" kind of distribution: the Pretty_Empty_closure has 213 uses and there are about as many closures with 1 uses as there are closures with 2 and 3 uses combined. A possible response to these figures is to move to a scheme with lazy construction of top-level _closures. We could create the _closure for a top level import on demand (I think there should be enough information in the .hi to do this) and then perhaps use C++-template instantiation linking semantics to common up definitions arising from distinct object files. These _closures would never be marked as exported. This should cut the number of exported symbols by 32k at a stroke. The only bit of information we will need to export about a top-level definition is the _info. Sound reasonable? Is this something we would want to do? Max _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
