So I saw that there are instructions in the readme about using -flate-specialise -fspecialise-aggressively, which I tried out.
But when the file that runs everything in IO is compiled, it takes about 13 cpu minutes and fills up the 32G ram without terminating.
Is this only feasible for smaller programs?
So I saw that there are instructions in the readme about using
-flate-specialise -fspecialise-aggressively
, which I tried out.But when the file that runs everything in
IO
is compiled, it takes about 13 cpu minutes and fills up the 32G ram without terminating.Is this only feasible for smaller programs?
interestingly, in ghci these options still have a quite noticable effect on the memory footprint, I thinknope, just a fluke
woah, I thought only
-fexpose-all-unfoldings
is this badI'll try it on a smaller program
I've both on too and haven't noticed something that dramatic, but maybe I'm not that heavy on effect usage/code size in general
I'd say it's about 50 effects in 350 files. not much of a benchmark but you can roughly estimate
it looks like
-fexpose-all-unfoldings
is used despite not being activated by me, is that normal?looks like
reflex-platform
activates thatreflex-platform
has control over your build configuration?yeah, it's a bit intrusive :sweat_smile: using nixpkgs'
overrides
thing for haskell package sets allows you to interfer wherever you wantI'm currently splitting the project in two, isolating the frontend
though I'm not certain that that's the cause, but it's the only place I found the option
FTR, it's working fine without
-fexpose-all-unfoldings
, but the memory dynamic is the samewhat do you mean? compilation terminates now?
yeah
and by memory I mean runtime behaviour. I guess I should have mentioned that I'm trying (still) to plug memory leaks