Strictness in UniqFM
Ian Lynagh
igloo at earth.li
Tue Feb 5 08:59:15 EST 2008
On Tue, Feb 05, 2008 at 10:51:29AM +0000, Simon Peyton-Jones wrote:
>
> hunk ./compiler/utils/UniqFM.lhs 701
> - | j ==# i = mkLeafUFM j (f old new)
> + | j ==# i = mkLeafUFM j $! f old new
>
> This gives UniqFM a very odd behaviour: it becomes strict in the *range* (element type) when, but only when, you insert a second element with the same key as an existing one.
Ah, true, it is rather inconsistent. The problem, IIRC, was that we were
doing lots of plusUFM's, so f was essentially const, but we were leaking
a lot of space keeping the unused value around. So it's f, not old/new,
that I really wanted to evaluate.
I did at some point try making UniqFM strict, but that caused memory
usage to head off to infinity, possibly due to this:
> I could just about imagine that making UniqFM *always* strict in its elements might make sense. At least it would be consistent. The one place I know we'd have to fix (by adding an extra Lift) is in the forkM in LoadIface.loadDecl. But otherwise it'd probably be ok.
I'll take a deeper look at making it strict.
Thanks
Ian
More information about the Cvs-ghc
mailing list