
On 02 February 2005 13:38, Duncan Coutts wrote:
I'm looking for advice on how to figure out why some piece of code is allocating memory when I think it ought to be able to work in constant space.
In these cases we cannot turn on traditional profiling since that would interfere with the optimisations we are relying on to eliminate most of the other memory allocations.
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] ]
(Don't worry about all those random constants, it's just test code!)
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. Cheers, Simon

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) Duncan
participants (2)
-
Duncan Coutts
-
Simon Marlow