Re: Profiling and analysing space usage

[Ketil Malde]

Alistair Bayley [EMAIL PROTECTED] writes:

I'm no expert, but since nobody else seems to have answered:

  - is my analysis of the space usage correct i.e. allocation in the
 loop function is very short-lived and nothing to worry about?

IME, that would be the typical case.

  - is there anything I can do to reduce the memory usage, or is it
 already minimal, assuming that I'm happy with the size of the
 STArrays? I realise I could use, say, PackedStrings

Slightly more general, you could use unboxed STUArrays.  Still limited
to a few built-in data types, and strict.  E.g. a STUArray Int Word8
would only take up one byte per element, an STArray would store a
(4 byte) pointer in each cell, pointing either to a Word8 value, or to
a lazy thunk for computing it.

At least as far as I understand it.

(Manuel's paper notwithstanding, I still have the feeling that
*UArrays should be *StrictArrays, and unboxing should be left as a
compiler optimization (which then could apply to arbitrary element
types, as long as they were strict.) 

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: hat, ghc

[Malcolm Wallace]

Frederik Eaton [EMAIL PROTECTED] writes:

 By the way, can I make a request to have the hmake default be to use
 the environment?

Ian Lynagh recently added this capability to hmake, but it wasn't
documented (until yesterday).  The relevant option is
hmake-config add-dyn ghc
which causes the version of ghc to be probed every time hmake is run,
rather than only once at configure-time.  Thus, it should pick up
the current environment settings as needed.

 Now, it appears to be looking for 'ghc-pkg' in the library directory
 of 'ghc' (rather, again, than in $PATH)

Well, hmake absolutely needs to use the ghc-pkg that belongs to the
particular version of ghc.  The heuristic used to find it might be
slightly fragile, but it is the best available, and indeed it is
based on the information given by ghc itself.  If the executable
has been moved such that querying ghc for its location is no longer
reliable, that's tough to fix.

Regards,
Malcolm
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users