Opened 10 years ago

Closed 8 years ago

Last modified 4 years ago

#3294 closed bug (wontfix)

Large compilation time/memory consumption

Reported by: pumpkin Owned by: simonmar
Priority: low Milestone: 7.4.1
Component: Compiler Version: 6.10.3
Keywords: Cc:
Operating System: MacOS X Architecture: x86
Type of failure: Compile-time performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by igloo)

When compiling the attached test case in the following way:

airpumpkin:integer-benchmark pumpkin$ time ghc -O2 --make -o big Big.hs
[1 of 1] Compiling Main             ( Big.hs, Big.o )
Linking big ...

real	1m29.336s
user	1m18.300s
sys	0m6.816s

You can see it takes a while to compile, and uses 640 MB of RAM during compilation.

Attachments (3)

Big.hs (27.1 KB) - added by pumpkin 10 years ago.
no_opt.png (98.4 KB) - added by igloo 10 years ago.
opt.png (100.0 KB) - added by igloo 10 years ago.

Download all attachments as: .zip

Change History (17)

Changed 10 years ago by pumpkin

Attachment: Big.hs added

comment:1 Changed 10 years ago by igloo

Description: modified (diff)
difficulty: Unknown

Changed 10 years ago by igloo

Attachment: no_opt.png added

Changed 10 years ago by igloo

Attachment: opt.png added

comment:2 Changed 10 years ago by igloo

Milestone: 6.12.1

Thanks for the report. I've attached some space profiles with and without -O. It looks like it is the codegen taking all the time and space.

comment:3 Changed 10 years ago by simonmar

Owner: set to simonmar

Yes, the register allocator looks like a culprit. Try -fregs-graph? I'm fairly familiar with the linear register allocator anyway, so I'll take a look.

comment:4 Changed 10 years ago by simonmar

The NCG has been leaking again, I just fixed it:

Fri Sep 11 16:28:12 BST 2009  Simon Marlow <marlowsd@gmail.com>
  * Fix a space leak in the native code gen (again)

This does reduce the peak memory usage for this test quite a lot, but we're still spending a lot of time in the NCG, and that needs investigating. Space leak test added as space_leaks/T3294, so hopefully this won't re-occur.

comment:5 Changed 10 years ago by simonmar

Type of failure: Compile-time performance bug

comment:6 Changed 10 years ago by igloo

Milestone: 6.12.16.12 branch

comment:7 Changed 9 years ago by igloo

Milestone: 6.12 branch6.12.3

comment:8 Changed 9 years ago by igloo

Milestone: 6.12.36.14.1
Priority: normallow

comment:9 Changed 9 years ago by igloo

Milestone: 7.0.17.0.2

comment:10 Changed 9 years ago by igloo

Milestone: 7.0.27.2.1

comment:11 Changed 9 years ago by altaic

Regarding the space leak, T3294 fails for me with HEAD on OS X 10.6 (x86_64):

bytes allocated 4624199648 is more than maximum allowed 1500000000
*** unexpected failure for T3294(normal)

I've also disabled the outofmem tests (ticket #1791), since it tends to bring my system to a grinding halt due to swapping.

comment:12 Changed 8 years ago by igloo

Milestone: 7.2.17.4.1

comment:13 Changed 8 years ago by simonmar

Resolution: wontfix
Status: newclosed

I have profiled the NCG, and although we are spending a lot of time in there (70% when compiling T3294.hs without -O), there are no obvious culprits, it's a fairly flat profile. So I'm closing this ticket.

comment:14 Changed 4 years ago by Thomas Miedema <thomasmiedema@…>

In f903949/ghc:

Pretty: improving the space/time performance of vcat, hsep, hcat (#10735)

After 5d57087e314bd484dbe14958f9b422be3ac6641a ("Pretty: fix a broken
invariant"), T3294 showed 50% more max_bytes_used (#3294). After this
commit, max_bytes_used is back to what it was before, and the test
passes again.

This is a backport of a bug fix by Benedikt Huber (#2393), from commit
1e50748beaa4bd2281d323b18ea51c786bba04a1 in the pretty library.

From https://mail.haskell.org/pipermail/libraries/2008-June/009991.html:

    vcat (hsep,cat) is implemented in an unneccessarily strict way.
    We only get some output after all of vcat's arguments are evaluated
    and checked against being Empty.
    This can be improved by only checking the right argument of foldr
    against being Empty, and
    then applying an Empty-filter on the resulting Doc. Space improvement
    is obvious.
    The microbenchmark (code.haskell.org/~bhuber/Text/PrettyPrint/
    HughesPJPerfCheck.hs) suggests that
    the improvements in time are remarkable too.
Note: See TracTickets for help on using tickets.