debugging memory allocations

Simon Marlow simonmar at microsoft.com
Mon Feb 7 06:28:44 EST 2005


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


More information about the Glasgow-haskell-users mailing list