ghc -O2 out of memory

I've written a program that reads a Excel file, parses the contents and generates a haskell module. Every cell in the xls has it's own function in the module. This worked fine. Now I have a bigger xls. The resulting module Xls.hs contains 30000 lines haskell code (without comment). I created a testprogram test.hs that calculates and prints one cell. I did ghc --make test.hs and everything works fine. The generated execuatable is very slow. I did ghc --make -O2 test.hs. The compilations takes 15 minutes and aborts with 'ghc: out of memory'. I'am working on Win 7 64 bits , ghc version = 7.8.3. What can I do to fix this? I do need -O2. I found with smaller xls's that optimization speeds up the executable dramatically. Before I start experimenting, does it help to split up the xls .hs in seperate files? I.e. the cells that refer to other cells and cells that don't refer to other cells. Or will I still get 'out of memory' because the optimization is global? Kees

You definitely don't want 30,000 lines in a single module. You should split this into separate modules, but be aware that the way you split them can affect how your program is e.g. inlined -- there can be performance implications.
Tom
El Mar 7, 2015, a las 10:56, "Kees Bleijenberg"
I’ve written a program that reads a Excel file, parses the contents and generates a haskell module. Every cell in the xls has it’s own function in the module. This worked fine. Now I have a bigger xls. The resulting module Xls.hs contains 30000 lines haskell code (without comment). I created a testprogram test.hs that calculates and prints one cell. I did ghc --make test.hs and everything works fine. The generated execuatable is very slow. I did ghc --make –O2 test.hs. The compilations takes 15 minutes and aborts with ‘ghc: out of memory’. I’am working on Win 7 64 bits , ghc version = 7.8.3.
What can I do to fix this? I do need –O2. I found with smaller xls’s that optimization speeds up the executable dramatically. Before I start experimenting, does it help to split up the xls .hs in seperate files? I.e. the cells that refer to other cells and cells that don’t refer to other cells. Or will I still get ‘out of memory’ because the optimization is global?
Kees
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

I have some code generation from xml producing files this big. Not going well :-( I’m make TH functions and will generate much smaller files. Hopefully the compiler expansion the templates is better than a big file full of source code. On Mar 7, 2015, at 10:17 AM, amindfv@gmail.com wrote:
You definitely don't want 30,000 lines in a single module. You should split this into separate modules, but be aware that the way you split them can affect how your program is e.g. inlined -- there can be performance implications.
Tom
El Mar 7, 2015, a las 10:56, "Kees Bleijenberg"
escribió: I’ve written a program that reads a Excel file, parses the contents and generates a haskell module. Every cell in the xls has it’s own function in the module. This worked fine. Now I have a bigger xls. The resulting module Xls.hs contains 30000 lines haskell code (without comment). I created a testprogram test.hs that calculates and prints one cell. I did ghc --make test.hs and everything works fine. The generated execuatable is very slow. I did ghc --make –O2 test.hs. The compilations takes 15 minutes and aborts with ‘ghc: out of memory’. I’am working on Win 7 64 bits , ghc version = 7.8.3.
What can I do to fix this? I do need –O2. I found with smaller xls’s that optimization speeds up the executable dramatically. Before I start experimenting, does it help to split up the xls .hs in seperate files? I.e. the cells that refer to other cells and cells that don’t refer to other cells. Or will I still get ‘out of memory’ because the optimization is global?
Kees
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On 07-03-2015 16:56, Kees Bleijenberg wrote:
I've written a program that reads a Excel file, parses the contents and generates a haskell module. Every cell in the xls has it's own function in the module. This worked fine.
Now I have a bigger xls. The resulting module Xls.hs contains 30000 lines haskell code (without comment). I created a testprogram test.hs that calculates and prints one cell.
I did ghc --make test.hs and everything works fine. The generated execuatable is very slow.
I did ghc --make -O2 test.hs. The compilations takes 15 minutes and aborts with 'ghc: out of memory'. I'am working on Win 7 64 bits , ghc version = 7.8.3.
What can I do to fix this? I do need -O2. I found with smaller xls's that optimization speeds up the executable dramatically.
Before I start experimenting, does it help to split up the xls .hs in seperate files? I.e. the cells that refer to other cells and cells that don't refer to other cells. Or will I still get 'out of memory' because the optimization is global?
Just out of curiousity, are you adding explicit type annotations? I imagine that type inference (rather than just checking) would add considerable overhead in pathological cases, especially if GHC is using a SAT-solver based approach (which I believe it is, these days). Regards,

Bardur, -----Oorspronkelijk bericht----- Van: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] Namens Bardur Arantsson Verzonden: zaterdag 7 maart 2015 19:26 Aan: haskell-cafe@haskell.org Onderwerp: Re: [Haskell-cafe] ghc -O2 out of memory On 07-03-2015 16:56, Kees Bleijenberg wrote:
I've written a program that reads a Excel file, parses the contents and generates a haskell module. Every cell in the xls has it's own function in the module. This worked fine.
<snip> Just out of curiousity, are you adding explicit type annotations? I imagine that type inference (rather than just checking) would add considerable overhead in pathological cases, especially if GHC is using a SAT-solver based approach (which I believe it is, these days). ---------------- Yes. Every cell is a top level function with a type annotation. All cells have the same type. I was afraid that splitting the module doesn't help. Kees _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On 03/07/2015 01:58 PM, Kees Bleijenberg wrote:
Yes. Every cell is a top level function with a type annotation. All cells have the same type. I was afraid that splitting the module doesn't help.
Kees
You don't even have to try very hard. Try compiling a module with a hard-coded list of a million integers. Boom.
participants (5)
-
amindfv@gmail.com
-
Bardur Arantsson
-
Kees Bleijenberg
-
Michael Jones
-
Michael Orlitzky