ANNOUNCE: GHC survey results

Bulat Ziganshin bulatz at
Wed Jun 29 10:17:55 EDT 2005

Hello Simon,

Wednesday, June 29, 2005, 1:03:06 PM, you wrote:

>> 1) GHCi compiles to bytecode several times faster than GHC makes
>> unoptimized compilation. can unoptimized GHC compilation just create
>> bytecode (as Ocaml does)?

SM> Do you really mean "several times faster"?  My impression is that it's a
SM> few percent faster, if at all.  Some measurements would be good.  We've

duron 1ghz, 4000 source lines in 14 modules:
ghc compile - 18 secs
ghc linking - 2 secs
ghci load - 8 secs
runhugs - 0.9 secs

so with bytecode i will get 2 times faster compilation, but it still 10
times worse than with HUGS. i seen a plans of integrating HUGS and GHC
run-time environments but as i see it was not implemented

btw, are you profiled GHC? what processes in compilation need most

SM> thought about compiling to persistent byte code in the past, but the
SM> gains never seemed to be worth the effort: we'd need a byte-code
SM> serialiser and loader.

you already have Binary.hs as a base, may be creating serializer will
be not so great work?


SM> I've read that article, and I think it's an interesting idea.  I can't
SM> disagree with the arguments put forward, but somehow, the cure seems a
SM> bit painful.

at least from User point of view, this looks beatiful. from viewpoint
of library creator/maintainer this can create some problems. but i
think it's not needed to create old interfaces to new libs for each
library. saving old library version will be enough. so, for example,
we will have libraries directory with newest versions of bundled libs
and libversions directory, which will contain Data.Map.6.2.hs and so

i still waiting an answers about "real world" questions :)

btw, in Pugs sources (
there is Unicode.hs module wich can classify and convert full range of
Unicode symbols under any OS. i don't understand - is this module
already included in GHC 6.5? if not, it would be good addition

Best regards,
 Bulat                            mailto:bulatz at

More information about the Glasgow-haskell-users mailing list