GitLab

We now use *_range_field everywhere instead

Residency is a very wobbly number; it depends on GC sampling time.
So I don't think this is a real regression.

Reason unknown. The rise was present before
    commit d5b5d488
    Author: Ian Lynagh <ian@well-typed.com>
    Date:   Wed Dec 12 17:12:13 2012 +0000

    Use ByteString rather than FastBytes inside FastZString

    Slow nofib Compile Times difference looks like just noise:
    -1 s.d.        -2.9%
    +1 s.d.        +2.9%
    Average        -0.1%
however.

failures

Please folks, remember failing perf tests are not expected and should
always be investigated.  In particular I have no idea why T4801 is now
failing - I narrowed it down to something around 30 Sep, but can't see
any commits around that date that could have caused it and it has
jumped by more than 10%.

Compiling with -dynamic (perhaps due to -fPIC being enabled?) seems
to require significantly more allocation:

=====> T1969(normal) 1 of 14 [0, 0, 0]
cd . && '/home/ian/ghc/git/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T1969.hs   +RTS -V0 -tT1969.comp.stats --machine-readable -RTS -dcore-lint >T1969.comp.stderr 2>&1
bytes allocated 669128520 is more than 1% greater than the expected value, 641959976 648379575.76
*** unexpected failure for T1969(normal)

=====> T4801(normal) 3 of 14 [0, 1, 0]
cd . && '/home/ian/ghc/git/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T4801.hs   +RTS -V0 -tT4801.comp.stats --machine-readable -RTS  >T4801.comp.stderr 2>&1
max_bytes_used 26928312 is more than 15% greater than the expected value, 18500000 21275000.0
peak_megabytes_allocated 66 is more than 20% greater than the expected value, 50 60.0
bytes allocated 522280144 is more than 10% greater than the expected value, 360243576 396267933.6
*** unexpected failure for T4801(normal)

=====> T783(normal) 9 of 14 [0, 2, 0]
cd . && '/home/ian/ghc/git/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T783.hs   +RTS -V0 -tT783.comp.stats --machine-readable -RTS  >T783.comp.stderr 2>&1
bytes allocated 506284808 is more than 10% greater than the expected value, 436927840 480620624.0
*** unexpected failure for T783(normal)

I decreased it yesterday, and now I'm putting it back up again,
but not as far as it was. I'm not sure what caused these changes
but it doesn't matter because this test checks that the type checker
gets out of an infinite loop.

Some wibbles due to recent changes. Some things got better, some got
worse, but nothing drastic.

Looking at the ticky output before and after the FastString patches,
the extra allocation seems to be in pprName, and looking at the core
it looks like it's just caused by small differences in what does and
doesn't get inlined.

The actual size of the change is small: from 578940312 to 589671096.

We've been getting steadily worse on this test, this time we were
hovering on the borderline and failing sometimes so I've updated the
value.  It is a bit worrying though.

Apparently GHC got faster

It depends too much on when GC takes place, and bounces around
by 10% on this particular test.