Memory usage exploding for complex pattern matching

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Memory usage exploding for complex pattern matching

Victor Miraldo (UU)
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
https://ghc.haskell.org/trac/ghc/ticket/11195

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.

Our actual non-minimal scenario runs out of memory on a 16GB RAM machine.

We tried with ghc 8.4.2, 8.0.2 and 7.10.3 and ghc-HEAD; all of those showed
a similar problem, although the older ghc's used less memory.

Do you have any suggestions to make our code finish compiling without running
out of memory?

Thanks!!
Victor

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Minimal.hs (63K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Memory usage exploding for complex pattern matching

Ben Gamari-2
"Victor Miraldo (UU)" <[hidden email]> writes:

> 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
> https://ghc.haskell.org/trac/ghc/ticket/11195
>
> 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 (when exhaustiveness checking
happens). Are you certain that the exhaustiveness checker is the
responsible party?

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Memory usage exploding for complex pattern matching

Matthew Pickering
In reply to this post by Victor Miraldo (UU)
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)
<[hidden email]> wrote:

> 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
> https://ghc.haskell.org/trac/ghc/ticket/11195
>
> 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.
>
> Our actual non-minimal scenario runs out of memory on a 16GB RAM machine.
>
> We tried with ghc 8.4.2, 8.0.2 and 7.10.3 and ghc-HEAD; all of those showed
> a similar problem, although the older ghc's used less memory.
>
> Do you have any suggestions to make our code finish compiling without running
> out of memory?
>
> Thanks!!
> Victor
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Memory usage exploding for complex pattern matching

Victor Miraldo (UU)
In reply to this post by Victor Miraldo (UU)
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 e-mail. The code
that triggers the really bad case is not much bigger. It is divided in
many more modules, though.

Cheers,
Victor
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Memory usage exploding for complex pattern matching

Victor Miraldo (UU)
In reply to this post by Victor Miraldo (UU)
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 (when exhaustiveness checking
> happens). Are you certain that the exhaustiveness checker is the
> responsible party?

Not at all! In fact, I ran some comparisons with "-ddump-phases" and
plotted those.
I'm attaching the graphs here. From base to "added E" we added 16 more
pattern matches,
then each "added" phase is an additional 16 pattern matches. The
simplifier stands out there.

I couldn't run a bigger case as I had hit the ceiling of my machine.

Cheers,
Victor

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

SpacePerPhase.png (65K) Download Attachment
TimePerPhase.png (61K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Memory usage exploding for complex pattern matching

Ben Gamari-2
"Victor Miraldo (UU)" <[hidden email]> 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 GB, with that peak
>> occurring during renaming, not desugaring (when exhaustiveness checking
>> happens). Are you certain that the exhaustiveness checker is the
>> responsible party?
>
> Not at all! In fact, I ran some comparisons with "-ddump-phases" and
> plotted those.
> I'm attaching the graphs here. From base to "added E" we added 16 more
> pattern matches,
> then each "added" phase is an additional 16 pattern matches. The
> simplifier stands out there.
>
> I couldn't run a bigger case as I had hit the ceiling of my machine.
>
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) dramatically
reduces desugarer allocations (to around 60MByte). It looks like you are right.

Unfortunately, it's not clear what can be done to work around this short of
disabling the match checker for the entire module, as suggested by
mpickering. Ideally we would have some notion of local warning flags
(e.g. #602), allowing us to disable this (rather expensive) warning for
generated code. Sadly, we aren't there yet. Perhaps you would like to
propose such a mechanism?

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Memory usage exploding for complex pattern matching

GHC - devs mailing list
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

| -----Original Message-----
| From: ghc-devs <[hidden email]> On Behalf Of Ben Gamari
| Sent: 29 March 2018 17:32
| To: Victor Miraldo (UU) <[hidden email]>
| Cc: [hidden email]
| Subject: Re: Memory usage exploding for complex pattern matching
|
| "Victor Miraldo (UU)" <[hidden email]> 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 GB, with that
| peak
| >> occurring during renaming, not desugaring (when exhaustiveness
| checking
| >> happens). Are you certain that the exhaustiveness checker is the
| >> responsible party?
| >
| > Not at all! In fact, I ran some comparisons with "-ddump-phases" and
| > plotted those.
| > I'm attaching the graphs here. From base to "added E" we added 16 more
| > pattern matches,
| > then each "added" phase is an additional 16 pattern matches. The
| > simplifier stands out there.
| >
| > I couldn't run a bigger case as I had hit the ceiling of my machine.
| >
| 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) dramatically
| reduces desugarer allocations (to around 60MByte). It looks like you are
| right.
|
| Unfortunately, it's not clear what can be done to work around this short
| of
| disabling the match checker for the entire module, as suggested by
| mpickering. Ideally we would have some notion of local warning flags
| (e.g. #602), allowing us to disable this (rather expensive) warning for
| generated code. Sadly, we aren't there yet. Perhaps you would like to
| propose such a mechanism?
|
| Cheers,
|
| - Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Memory usage exploding for complex pattern matching

Victor Miraldo (UU)
In reply to this post by Ben Gamari-2
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) dramatically
> reduces desugarer allocations (to around 60MByte). It looks like you are
> right.

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))`).

I saw many warnings about the pattern match checker exceeding the iterations
I specified:

  warning:
    Pattern match checker exceeded (0) iterations in
    a case alternative. (Use -fmax-pmcheck-iterations=n
    to set the maximun number of iterations to n)

Which makes me wonder, is the option really stopping the checker or
just displaying something when it exceeds the given number?

> Unfortunately, it's not clear what can be done to work around this short
> of
> disabling the match checker for the entire module, as suggested by
> mpickering. Ideally we would have some notion of local warning flags
> (e.g. #602), allowing us to disable this (rather expensive) warning for
> generated code. Sadly, we aren't there yet. Perhaps you would like to
> propose such a mechanism?

You guys are much more indicated to propose mechanisms to fix this.
If you think this is a sensible mechanism to implement, sure! I'd be
happy to propose it.

@Simon

> 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.

Should I be the one creating it or adding the reproducer?
The closest I've seen is: https://ghc.haskell.org/trac/ghc/ticket/11195

> Maybe we should revert the (recent) patch that makes TH code behave like source code, until this pattern-match check business is solved.

Let me know when this happens, I'll be happy to test my code again!

Thanks!
Cheers,
Victor
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Memory usage exploding for complex pattern matching

Ben Gamari-2
"Victor Miraldo (UU)" <[hidden email]> 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
>> the pattern match checker (via -fmax-pmcheck-iterations=0) dramatically
>> reduces desugarer allocations (to around 60MByte). It looks like you are
>> right.
>
> 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?

> @Simon
>
>> 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.
>
> Should I be the one creating it or adding the reproducer?
> The closest I've seen is: https://ghc.haskell.org/trac/ghc/ticket/11195
>
Let's start with a fresh ticket; #11195 has a rather long history. Do
you think you could open it and attach your repro?

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Memory usage exploding for complex pattern matching

Victor Miraldo (UU)
In reply to this post by Victor Miraldo (UU)
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 I meant my whole code, not just the repro. I could have been more clear.
Nevertheless, I'm calling it through stack:

stack build --ghc-options="-fmax-pmcheck-iterations=0"

I have just ran the repro with and without
"-fmax-pmcheck-iterations=0" and got similar results to yours.

> Let's start with a fresh ticket; #11195 has a rather long history. Do
> you think you could open it and attach your repro?

Sure thing, will do it tomorrow!

Cheers,
Victor
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Memory usage exploding for complex pattern matching

Ben Gamari-2
"Victor Miraldo (UU)" <[hidden email]> writes:

> 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 I meant my whole code, not just the repro. I could have been more clear.
> Nevertheless, I'm calling it through stack:
>
I'll admit that I am a bit lost; Minimal.hs compiles for me with a
maximum residency of ~3.5 GBytes with both -O1 and the PM check enabled
using GHC 8.4.1. Is this not the repro you are referring to?

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Memory usage exploding for complex pattern matching

Victor Miraldo (UU)
In reply to this post by Victor Miraldo (UU)
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 I meant my whole code, not just the repro. I could have been more clear.
>> Nevertheless, I'm calling it through stack:
>>
> I'll admit that I am a bit lost; Minimal.hs compiles for me with a
> maximum residency of ~3.5 GBytes with both -O1 and the PM check enabled
> using GHC 8.4.1. Is this not the repro you are referring to?

I get the same behavior as you for Minimal.hs.

The "my code" above referred to the whole library that I'm developping.
In fact, the Minimal.hs file contains a distilled version of that library with
a template haskell splice that we are trying to use in one of our
fully fledged examples.

Do you want me to produce a larger "NotSoMinimal.hs" closer to the real thing?

Cheers,
Victor
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Memory usage exploding for complex pattern matching

Ben Gamari-2
"Victor Miraldo (UU)" <[hidden email]> writes:

> 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 I meant my whole code, not just the repro. I could have been more clear.
>>> Nevertheless, I'm calling it through stack:
>>>
>> I'll admit that I am a bit lost; Minimal.hs compiles for me with a
>> maximum residency of ~3.5 GBytes with both -O1 and the PM check enabled
>> using GHC 8.4.1. Is this not the repro you are referring to?
>
> I get the same behavior as you for Minimal.hs.
>
> The "my code" above referred to the whole library that I'm developping.
> In fact, the Minimal.hs file contains a distilled version of that library with
> a template haskell splice that we are trying to use in one of our
> fully fledged examples.
>
Okay, I just wanted to be certain we were indeed seeing the same
behavior. Indeed 3.5 GB is quite a lot of memory for a 700 LoC program,
even one with the deep matches seen in Minimal.hs.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Memory usage exploding for complex pattern matching

Victor Miraldo (UU)
In reply to this post by Victor Miraldo (UU)
Hello all,

Following up on this, I have created a trac ticket
https://ghc.haskell.org/trac/ghc/ticket/14987#no2 as
suggested a couple days ago.

In order to try to hack my way through and get my library to compile,
I tried progressively
adding more and more pattern synonyms to try to avoid exhaustiveness
checking,yet, something
really surprising happened. Big examples have type errors where small
ones don't!

I tried documenting the process in a repository:
https://github.com/VictorCMiraldo/ghc-14987-repro-pipeline

Unfortunately, however, I couldn't get the self contained repros in
the repository above to throw
type errors. Hence, I'm attaching my full code. Compiling the file
src/Generics/MRSOP/Examples/GoAST.hs
gives type errors, even though it is being generated by the same
template haskell code as the other
files inside Examples, all of which compile just fine. To trigger the
error, just run `stack build`.

It really is a shame that the combination of pattern synonyms that
shows the best memory performance
crashes completely on bigger examples.

Any suggestions are appreciated, thank you very much!

Have a great weekend!
Cheers,
Victor



On Fri, Mar 30, 2018 at 5:23 PM, Ben Gamari <[hidden email]> wrote:

> "Victor Miraldo (UU)" <[hidden email]> writes:
>
>> 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 I meant my whole code, not just the repro. I could have been more clear.
>>>> Nevertheless, I'm calling it through stack:
>>>>
>>> I'll admit that I am a bit lost; Minimal.hs compiles for me with a
>>> maximum residency of ~3.5 GBytes with both -O1 and the PM check enabled
>>> using GHC 8.4.1. Is this not the repro you are referring to?
>>
>> I get the same behavior as you for Minimal.hs.
>>
>> The "my code" above referred to the whole library that I'm developping.
>> In fact, the Minimal.hs file contains a distilled version of that library with
>> a template haskell splice that we are trying to use in one of our
>> fully fledged examples.
>>
> Okay, I just wanted to be certain we were indeed seeing the same
> behavior. Indeed 3.5 GB is quite a lot of memory for a 700 LoC program,
> even one with the deep matches seen in Minimal.hs.
>
> Cheers,
>
> - Ben
>

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

generics-mrsop.zip (42K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Memory usage exploding for complex pattern matching

GHC - devs mailing list
|  In order to try to hack my way through and get my library to compile,
|  I tried progressively adding more and more pattern synonyms to try to
|  avoid exhaustiveness checking,yet, something really surprising
|  happened. Big examples have type errors where small ones don't!

That is strange.  Sounds as if you want a new Trac report, just for that.

Simon

|  -----Original Message-----
|  From: Victor Miraldo (UU) <[hidden email]>
|  Sent: 07 April 2018 12:02
|  To: Ben Gamari <[hidden email]>
|  Cc: Simon Peyton Jones <[hidden email]>; [hidden email]
|  Subject: Re: Memory usage exploding for complex pattern matching
|  
|  Hello all,
|  
|  Following up on this, I have created a trac ticket
|  https://ghc.haskell.org/trac/ghc/ticket/14987#no2 as suggested a
|  couple days ago.
|  
|  In order to try to hack my way through and get my library to compile,
|  I tried progressively adding more and more pattern synonyms to try to
|  avoid exhaustiveness checking,yet, something really surprising
|  happened. Big examples have type errors where small ones don't!
|  
|  I tried documenting the process in a repository:
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
|  b.com%2FVictorCMiraldo%2Fghc-14987-repro-
|  pipeline&data=02%7C01%7Csimonpj%40microsoft.com%7C59fdacad7f94412d665e
|  08d59c7717f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636586957847
|  493826&sdata=bnuBOL%2FELkmJahidX%2BmWPSDDf%2BuKlJkBAJyFVyY%2Bel8%3D&re
|  served=0
|  
|  Unfortunately, however, I couldn't get the self contained repros in
|  the repository above to throw type errors. Hence, I'm attaching my
|  full code. Compiling the file src/Generics/MRSOP/Examples/GoAST.hs
|  gives type errors, even though it is being generated by the same
|  template haskell code as the other files inside Examples, all of which
|  compile just fine. To trigger the error, just run `stack build`.
|  
|  It really is a shame that the combination of pattern synonyms that
|  shows the best memory performance crashes completely on bigger
|  examples.
|  
|  Any suggestions are appreciated, thank you very much!
|  
|  Have a great weekend!
|  Cheers,
|  Victor
|  
|  
|  
|  On Fri, Mar 30, 2018 at 5:23 PM, Ben Gamari <[hidden email]>
|  wrote:
|  > "Victor Miraldo (UU)" <[hidden email]> writes:
|  >
|  >> 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 I meant my whole code, not just the repro. I could have been
|  more clear.
|  >>>> Nevertheless, I'm calling it through stack:
|  >>>>
|  >>> I'll admit that I am a bit lost; Minimal.hs compiles for me with a
|  >>> maximum residency of ~3.5 GBytes with both -O1 and the PM check
|  >>> enabled using GHC 8.4.1. Is this not the repro you are referring
|  to?
|  >>
|  >> I get the same behavior as you for Minimal.hs.
|  >>
|  >> The "my code" above referred to the whole library that I'm
|  developping.
|  >> In fact, the Minimal.hs file contains a distilled version of that
|  >> library with a template haskell splice that we are trying to use in
|  >> one of our fully fledged examples.
|  >>
|  > Okay, I just wanted to be certain we were indeed seeing the same
|  > behavior. Indeed 3.5 GB is quite a lot of memory for a 700 LoC
|  > program, even one with the deep matches seen in Minimal.hs.
|  >
|  > Cheers,
|  >
|  > - Ben
|  >
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs