#10812: High memory usage ---------------------------------+----------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by bgamari): The problem is that the GC isn't being performed after traversing `xr`; if you manually insert a `performGc` before the `threadDelay` then you will find things behave as you expect. For the record, the given test seems to behave as expected on my machine. My testing methodology was rather crude, {{{ $ ghc -O Test.hs; ./Test & pid=$!; while true; do cat /proc/$pid/stat >> stat; sleep 0.01; done $ ipython --pylab
a = genfromtxt('stat') vsize = a[:,22] # see proc(5) plot(vsize / 1024**2) ylabel('vsize / megabytes') xlabel('something approximating time') }}}
With `[1..10000000]` `vsize` peaked around 1.8GB around 3 seconds after starting the process. With the testcase provided above `vsize` remained at this peak for the remaining duration of the program. With a manual `performGC` after the traversal, however, it dropped to essentially zero around a second after plateauing. It stayed there for the rest of the execution. The moral of the story is if you want the runtime to GC at a given point, you must tell it. GC occurs due to allocation. Given that there is essentially no allocation after the traversal it isn't terribly surprising that no GC is occurring. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10812#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler