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