[GHC] #3041: Arch independent binary representations

GHC trac at galois.com
Thu Mar 5 07:43:51 EST 2009


#3041: Arch independent binary representations
---------------------------------+------------------------------------------
    Reporter:  nomeata           |        Owner:         
        Type:  feature request   |       Status:  new    
    Priority:  normal            |    Milestone:         
   Component:  Compiler          |      Version:  6.10.1 
    Severity:  normal            |   Resolution:         
    Keywords:                    |   Difficulty:  Unknown
    Testcase:                    |           Os:  Linux  
Architecture:  Unknown/Multiple  |  
---------------------------------+------------------------------------------
Comment (by duncan):

 Replying to [comment:9 simonmar]:
 > Replying to [comment:7 igloo]:
 >
 > > Is there a reason for GHC not to use `Data.Binary` too? The only
 reason I can think of would be to avoid the extra dependency, but if
 haddock uses it then the GHC build depends on it anyway. Personally, I
 don't think it's a strong enough reason to maintain our own Binary anyway.
 >
 > I've been lead to believe that the performance of `Data.Binary` isn't as
 good as our `Binary` library.  I don't have figures to back that up, but
 performance of reading interface files is pretty important to us.  So I've
 been holding off on switching until `Data.Binary` has had some tuning.

 There was a regression in the performance of `Data.Binary` from ghc-6.8 to
 6.10 which is perhaps what you're thinking of. Prior to that it was
 several times faster (10x at the time of the binary-0.4 release) than
 `NewBinary` which I believe was basically ghc's binary implementation
 extracted into a standalone library. Don looked at the performance
 regression so is best placed to say if the latest release brings
 performance back up to what it was with 6.8.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3041#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the Glasgow-haskell-bugs mailing list