Opened 10 months ago

Last modified 10 months ago

#9234 new bug

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: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

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 (6)

comment:1 Changed 10 months 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.

Simon

comment:2 Changed 10 months 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 10 months ago by augustss

  • Description modified (diff)

comment:4 Changed 10 months 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 10 months 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 10 months ago by augustss (previous) (diff)

comment:6 Changed 10 months ago by augustss

  • Description modified (diff)
Note: See TracTickets for help on using tickets.