[GHC] #7561: Unnecessary Heap Allocations - Slow Performance

GHC cvs-ghc at haskell.org
Sun Jan 27 20:14:51 CET 2013


#7561: Unnecessary Heap Allocations - Slow Performance
-------------------------------+--------------------------------------------
    Reporter:  wurmli          |       Owner:                         
        Type:  bug             |      Status:  new                    
    Priority:  normal          |   Milestone:  7.8.1                  
   Component:  Compiler        |     Version:  7.6.1                  
    Keywords:                  |          Os:  Linux                  
Architecture:  x86_64 (amd64)  |     Failure:  Runtime performance bug
  Difficulty:  Unknown         |    Testcase:                         
   Blockedby:                  |    Blocking:                         
     Related:                  |  
-------------------------------+--------------------------------------------
Changes (by shachaf):

 * cc: shachaf@… (added)


Comment:

 For (1), I narrowed the bug down a bit -- it has nothing to do with Vector
 in particular. Here's a somewhat simpler version:

 {{{
 import Control.Applicative
 import Control.Monad
 import Control.Monad.ST
 import Data.STRef
 import System.Environment

 doLoop :: Int -> STRef s Int -> ST s ()
 doLoop n v = go ((< n) <$> readSTRef v)
   where
     go mbool = do
       t <- mbool
       when t $ modifySTRef v (+1) >> go mbool

 main :: IO ()
 main = do
    n <- read.head <$> getArgs
    print $ runST $ do { r <- newSTRef 0; doLoop n r; readSTRef r }

 }}}

 If you have a look at the Core for this program under normal -O2, you'll
 see that instead of sharing `n`, the `read` call from `main` is being
 moved all the way into the inner loop! This explains the significant
 slowdown.

 The code can probably be simplified further, but as it is even small
 changes to the program are enough to make the problem go away -- e.g.
 adding an SCC annotation in almost any part of `doLoop`, or evaluating `n`
 before passing it in, or shuffling code around too much.

 I haven't looked into (2). Either it's the same problem or one of these
 should be split out into a different ticket, presumably.

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



More information about the ghc-tickets mailing list