On 02 February 2005 18:42, Duncan Coutts wrote: > On Wed, 2005-02-02 at 17:01 +0000, Simon Marlow wrote: >> On 02 February 2005 13:38, Duncan Coutts wrote: >>> Would looking at the core files help? What would I be looking for? >>> >>> Here's a simple version that I would expect to run in constance >>> space. >>> >>> pixbufSetGreen :: Pixbuf -> IO () >>> pixbufSetGreen pixbuf = do >>> ptr <- pixbufGetPixels pixbuf >>> sequence_ >>> [ do pokeByteOff ptr (y*384+3*x) (0 ::Word8) >>> pokeByteOff ptr (y*384+3*x+1) (128::Word8) >>> pokeByteOff ptr (y*384+3*x+2) (96 ::Word8) | y <- >>> [0..127] , x <- [0..127] ] >>> >> >> Yes, let's see the core. Since you're interested in allocation, you >> might be better off with -ddump-prep rather than -ddump-simpl: the >> former has all the allocation made into explicit 'let' expressions >> ready for code generation. > > Ok, attached it the -ddump-prep for the version using pixbufSetGreen, > and another file for the longer more complicated one which is using > setWierdColour. Both versions do contain 'let's. > > I've also attached the original code. (which you won't be able to > build without hacking the gtk bits out of it)
I took a quick look at this, and one thing I noticed is that some deforestation isn't happening. There is still an explicit [0..127] being constructed/deconstructed. I don't think we'll be able to investigate this right now, so if you need performance immediately I suggest you rewrite the code using explicit recursion. Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users