On 30-Apr-2000, Ian Jackson <[EMAIL PROTECTED]> wrote:
> I've been using GHC's profiling support.  This gives me information
> about numbers of `allocations' (which I presume refers to memory
> allocations) and does indeed point the finger at the part of the
> program that I most suspected anyway.
> 
> I think the program is using too much CPU rather than too much memory
> because (a) my machine doesn't thrash and (b) the test case I'm using
> is not very large.

Thrashing is determined by the amount of live memory.
Allocations measure that amount of memory which is allocated,
but in general not all of the allocated memory will remain live.
Memory allocations that subsequently become garbage don't influence
the working set size much, but they do influence CPU usage, since it
takes quite a bit of CPU do the allocation and/or to garbage collect
it afterwards.

> * I added a reasonable amount of added strictness in `obvious' kind of
> places, but with no visible effect on performance.  Does adding
> strictness help with CPU use as well as with memory use ?  Where is it
> most beneficial to add strictness ?

It's most beneficial to add strictness annotations on data structures.
Compilers for lazy functional languages tend to do a reasonably good
job of inferring strictness of functions, but a lousy job of inferring
strictness of data constructors.

> * Most of my program is in a state-threading monad of my own (built
> out of normal functional pieces).  The main program (which is in the
> IO monad) invokes the `grind handle on state machine' function,
> passing the action to perform and the initial state and getting the
> new state back.  Is this good, bad, or ugly ?

That sounds OK to me.

> * In particular, the bit of code that seems to be slow is the part
> responsible for updating a part of the state whose type is broadly
> speaking
> 
>    Array (x,y) [value]
...
> In C I would have just had one big flat array and updated it in
> place.  How can I get a Haskell compiler to do the same ?

With ghc, you can use the `STArray' type defined in the `ST' module.

> * I really wanted a simple, flat, strict type rather than the lazy,
> nested [value].  I'm only using a list because I want to do a zipWith
> on it in the update function.  Also, the manual says that an Array is
> not strict in its contents, which doesn't seem helpful to me.

Rather than using Haskell's list type, which is lazy,
you can define your own strict list type

        data List t = Nil | Cons !t !(List t)

You can easily write a zipWith function for this type.

-- 
Fergus Henderson <[EMAIL PROTECTED]>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED]        |     -- the last words of T. S. Garp.

Reply via email to