Re: Memory usage exploding for complex pattern matching

Hello, >> I have just tried compiling my code with 8.4.2 and using >> -fmax-pmcheck-iterations=0, >> I gave GHC 12GB of ram and it still ran out (through `ulimit >> -v$((1024*1024*12))`). >> > Hmmm, I'm a bit confused. Why are our results so different? How > precisely are you invoking GHC? Here

Re: Memory usage exploding for complex pattern matching

"Victor Miraldo (UU)" writes: > Hello, > > @Ben > >> I tried 8.4 and indeed the renamer/typechecker takes dramatically less >> memory (yay!), leaving desugar as the largest allocator (allocating >> around 3GB) while compiling the minimal example. Furthermore, disabling

Re: Memory usage exploding for complex pattern matching

Hello, @Ben > I tried 8.4 and indeed the renamer/typechecker takes dramatically less > memory (yay!), leaving desugar as the largest allocator (allocating > around 3GB) while compiling the minimal example. Furthermore, disabling > the pattern match checker (via -fmax-pmcheck-iterations=0)

RE: Memory usage exploding for complex pattern matching

Let's make a Trac ticket for this (since there is a nice small reproducer). Or, if it seems a dup, attach the reproducer to some existing ticket. Maybe we should revert the (recent) patch that makes TH code behave like source code, until this pattern-match check business is solved. Simon |

Re: Memory usage exploding for complex pattern matching

"Victor Miraldo (UU)" writes: > Hello Ben, > > >>> We came up with a "minimal" example that at least is self contained and >>> triggers the problem; `runghc Minimal.hs` should finish with about 5GB of >>> RAM. >>> >> Hmm, with 8.2 I'm seeing a peak memory usage of 3.5

Re: Memory usage exploding for complex pattern matching

Hello Ben, >> We came up with a "minimal" example that at least is self contained and >> triggers the problem; `runghc Minimal.hs` should finish with about 5GB of >> RAM. >> > Hmm, with 8.2 I'm seeing a peak memory usage of 3.5 GB, with that peak > occurring during renaming, not desugaring

Re: Memory usage exploding for complex pattern matching

Hello! > You can turn off the pattern match checker, is that an option? How? > Can you post your code which shows the poor behaviour. It could be > good to profile that part of GHC to see if there are any easy gains > but it is known to be slow. I attached a minimal example in the original

Re: Memory usage exploding for complex pattern matching

You can turn off the pattern match checker, is that an option? Can you post your code which shows the poor behaviour. It could be good to profile that part of GHC to see if there are any easy gains but it is known to be slow. Cheers, Matt On Thu, Mar 29, 2018 at 3:16 PM, Victor Miraldo (UU)

Memory usage exploding for complex pattern matching

Dear ghc-devs, We are working on a library and came across quite high memory consumption when compiling some code (generated by TH). This memory issue seems to come from the exhaustiveness checker as we found in: https://ghc.haskell.org/trac/ghc/ticket/11163

Re: Question about indirectees of BLACKHOLE closures

I still don't understand the whole story with blackholes but I'll update the comments around the BLACKHOLE stack frame and/or wiki pages once I get a better understanding. Ömer 2018-03-26 21:47 GMT+03:00 Ben Gamari : > Simon Marlow writes: > >> The