performance regressions

Joachim Breitner mail at
Mon Dec 15 08:43:48 UTC 2014


Am Sonntag, den 14.12.2014, 22:37 -0500 schrieb Richard Eisenberg:
> Of course, I now see that it wasn't a full fix.
> This is all most assuredly my fault.

I wouldn’t call it a fault. Where wood is chopped, splinters must fall.
(Hopefully correct translation of a German idiom.)

We don’t _have_ to catch everything before it hits master, it is already
pretty good if we manage to catch and fix regressions later.

I guess we could use the known_broken feature of the test suite more
quickly, to signal that an issue is being worked on and to avoid others
from stumbling over test suite failures.

> - Travis has not picked up on these errors.

unfortunately, travis is slighly less useful since a few weeks due to
T5681 failing (possibly due to the use of LLVM-3.4), but I’m still
waiting for an reply on that issue.

But it wouldn’t have helped you: Travis generally skips all performance
tests. These used to be far less reliable when I set up travis (this got
better due to the removal of some of the max_bytes_allocated tests, and
also due to harbormaster and ghcspeed monitoring), and also because we
still hardly make the 50 minute deadline on Travis.

So do not rely on Travis for performance measurements.
(This is documented on, but
it needs to become common knowledge.)


Joachim “nomeata” Breitner
  mail at joachim-breitner.de
  Jabber: nomeata at  • GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the ghc-devs mailing list