...So the task at this point is to come up with some good benchmarks. There are essentially two ways to attack that problem. Either we can try to show a speed-up in allocation or we can try to show a speed-up due to

#5925: Add inline version of newArray# -------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 4258 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by jberryman): Replying to [comment:12 tibbe]: the better locality (e.g. constructor wrapping an array can now be allocated next to the array.) I don't understand this issue very well, but I wonder if you'd see any difference in running something like this through criterion: {{{ do let payload = P.newArray 32 0 :: IO (P.MutableArray (PrimState IO) Int) x <- newEmptyMVar y <- newEmptyMVar forkIO $ (replicateM_ 500 payload) >> putMVar x () forkIO $ (replicateM_ 500 payload) >> putMVar y () -- ... etc, for number of cores - 1 or so takeMVar x takeMVar y }}} ..using `payload = return ()` as the baseline measurement? Or maybe microbenchmark newArray followed by a read? Re. better locality, I have a real application: a Chan-like IORef linked list of small `MutableArray`s. Maybe creating/traversing a structure like that would show some improvement? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/5925#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler