Enabling profiling can significantly change the space behavior of programs. There may be some important optimizations that don't occur in the presence of profiling, and the profiling data itself takes some memory. I have to admit, I don't know a lot about GHC profiling so I'm afraid I can't be of much help.

Me neither. I tried several things: Just turning off the optimizations doesn't cause the problem. Optimization + profiling (-O -prof) has the same problem as -prof alone. It doesn't matter if -auto-all option is there or not. And the profiled program gobbles up all memory with or without the +RTS -p option.

If you can scale down the problem size to do your profiling, that may keep it from being OOM'd and let you get some useful data.

I'll try, but I doubt it. The program seems to misbehave at the very start of the execution.

...

The non-profiled version of the program runs perfectly well. In fact, the PatriciaLoMap from Edison seems to be about two to three times faster than Data.Map library for my purposes.

That's good to hear. What's the usage pattern?

As soon as I get the execution profile, I'll send it to you. But it's basically a lot of small maps, with few insertions, moderate lookups and folds, and lots of unions. The one function I'm missing from Data.Map library is mapAssoc, but I can manage without it. One thing you might find interesting about the usage pattern is that my keys are not actually of type Int, but they contain an Int field. To get around PatriciaLoMap's restriction that keys must be Ints, I'm abstracting it as follows: import qualified Data.Edison.Assoc.PatriciaLoMap as PLM newtype Map term = PLM (PLM.FM (Label, term)) map f (PLM map) = PLM (PLM.map (\ (k, v)-> (k, f k v)) map) foldWithKey f x (PLM map) = PLM.fold (uncurry f) x map filter f (PLM map) = PLM (PLM.filter (f . snd) map) adjust f k (PLM map) = PLM (PLM.adjust (right f) (labelId k) map) where right f (x, y) = (x, f y) lookupM k (PLM map) = fmap snd (PLM.lookupM (labelId l) map) ... I wonder if PatriciaLoMap would be faster if it applied this pattern internally? Basically, could a structure like the following one make sense in Edison itself? class Countable x where toInt :: x -> Int data Countable k => GenericPLM k v = PLM.FM (k, v)