Opened 6 years ago

Closed 4 years ago

#9234 closed bug (duplicate)

Compiled code performance regression

Reported by: augustss Owned by:
Priority: low Milestone:
Component: Compiler Version: 7.8.2
Keywords: Cc:
Operating System: Windows Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by augustss)

Upgrading from ghc 7.6 to 7.8 has slowed down our main application noticeably. This is with 32-bit Windows.

Here's some 7.2 numbers:

  INIT    time    0.00s  (  0.00s elapsed)
  MUT     time  287.78s  (290.41s elapsed)
  GC      time   87.39s  ( 88.43s elapsed)
  EXIT    time    0.00s  (  0.00s elapsed)
  Total   time  375.63s  (378.86s elapsed)

And corresponding 7.8 numbers:

  INIT    time    0.00s  (  0.00s elapsed)
  MUT     time  298.34s  (301.35s elapsed)
  GC      time   88.16s  ( 89.27s elapsed)
  EXIT    time    0.00s  (  0.00s elapsed)
  Total   time  386.93s  (390.62s elapsed)

This is not unexpected since every ghc upgrade so far has slowed down our code; it's just following the trend we expect.

Change History (7)

comment:1 Changed 6 years ago by simonpj

I'm more surprised about this. Generally I expect runtime performance to improve, not get worse. I do profile runtime performance more carefully, but my only benchmark suite is nofib.

Anything you can do to characterise what is slowing down would be extremely helpful. Providing benchmark programs would be extremely helpful. Lacking either, and I know that both are hard for you, it's hard to know how to help.


comment:2 Changed 6 years ago by tibbe

Could you set up a build bot the builds GHC HEAD and runs your application using it? That way we could better pinpoint when we regress.

GHC should of course have such a build bot itself, using some benchmark suite.

comment:3 Changed 6 years ago by augustss

Description: modified (diff)

comment:4 Changed 6 years ago by augustss

I did try to profile two different ghc versions another time to find out what happened, but the profile is very "smeared out", i.e., many things using a little time. The previous time I tried there was nothing that stuck out; everything just got a little slower.

The trend is fairly consistent, we lose 3-10% performance on every ghc upgrade.

comment:5 Changed 6 years ago by augustss

If we had more resources (human and machine) it would be interesting to keep up with ghc HEAD. But keeping up with ghc is neither effortless nor automatic. I've spent about 1.5 weeks upgrading from 7.6 to 7.8. It involves finding a set of packages that compiles with the new ghc, and fixing all the places in our code where the new ghc is incompatible with the old one. Note, I'm not complaining about having to do these changes, but we don't have the resources to do them continuously.

Last edited 6 years ago by augustss (previous) (diff)

comment:6 Changed 6 years ago by augustss

Description: modified (diff)

comment:7 Changed 4 years ago by thomie

Resolution: duplicate
Status: newclosed
Type of failure: None/UnknownRuntime performance bug

There are currently 184 open tickets concerning runtime performance. Since this one is the least actionable (doesn't have any code attached), I'm going to go ahead and close it.

nofib benchmark results are posted on nowadays, and the issue tracker is at

Note: See TracTickets for help on using tickets.