#7367: Optimiser / Linker Problem on amd64 --------------------------------------------+------------------------------ Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by rwbarton): wurmli, what's the matter with it? "800,100,272 bytes allocated in the heap" means that the total size of all the allocations done over the course of the program is 800,100,272 bytes. That's the expected size of 20 million (Int, Int) pairs which share their second field (`n`), plus a small amount of other stuff. It doesn't have anything to do with the size of the heap at any given time. The maximum heap size is shown separately: "50,520 bytes maximum residency" which is quite reasonable. Similarly your original program does not ever occupy 10 GB of heap at a time. If you look at the process in top you will see a memory usage close to "47,184 bytes maximum residency" (well probably more like a couple MB, to hold the program image, but not anything near 10 GB). I have no idea why the original program timed out on the language benchmark machines, but it wasn't due to it allocating 10 GB sequentially. Allocation of short-lived objects is very cheap. But it is not free, and this discussion has been about why current GHC produces a program that allocates a lot when GHC 7.4 did not. Eliminating the large amount of allocation might reduce the runtime by a few percent or so. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7367#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler