1. 16 Dec, 2014 1 commit
  2. 14 Dec, 2014 4 commits
  3. 11 Dec, 2014 1 commit
  4. 03 Dec, 2014 1 commit
  5. 22 Nov, 2014 1 commit
  6. 08 Oct, 2014 1 commit
  7. 07 Oct, 2014 1 commit
    • rwbarton's avatar
      Bump haddock.base perf numbers · e87135ce
      rwbarton authored
      We were so close to the max that the test failed if the pathname to
      the GHC repository was more than a few dozen characters, causing the
      haddock.base test to fail on Phab but not locally.
  8. 24 Sep, 2014 1 commit
    • Edward Z. Yang's avatar
      Update Cabal submodule & ghc-pkg to use new module re-export types · 4b648be1
      Edward Z. Yang authored and Herbert Valerio Riedel's avatar Herbert Valerio Riedel committed
      The main change is that Cabal changed the representation of module
      re-exports to distinguish reexports in source .cabal files versus
      re-exports in installed package registraion files.
      Cabal now also does the resolution of re-exports to specific installed
      packages itself, so ghc-pkg no longer has to do this. This is a cleaner
      design overall because re-export resolution can fail so it is better to
      do it during package configuration rather than package registration.
      It also simplifies the re-export representation that ghc-pkg has to use.
      Add extra ghc-pkg sanity check for module re-exports and duplicates
      For re-exports, check that the defining package exists and that it
      exposes the defining module (or for self-rexport exposed or hidden
      modules). Also check that the defining package is actually a direct
      or indirect dependency of the package doing the re-exporting.
      Also add a check for duplicate modules in a package, including
      re-exported modules.
      Test Plan:
      So far the sanity checks are totally untested. Should add some test
      case to make sure the sanity checks do catch things correctly, and
      don't ban legal things.
      Reviewers: austin, duncan
      Subscribers: angerman, simonmar, ezyang, carter
      Differential Revision: https://phabricator.haskell.org/D183
      GHC Trac Issues:
  9. 10 Sep, 2014 1 commit
    • Joachim Breitner's avatar
      Update performance numbers · 71c85300
      Joachim Breitner authored
      including some that are not failing yet, but did show a significant
      change, and some that Austing changed post-AMP, but where both
      harbormaster and ghcspeed reported something else. Numbers taken from
      the ghcspeed machine.
  10. 09 Sep, 2014 1 commit
    • Austin Seipp's avatar
      Make Applicative a superclass of Monad · d94de872
      Austin Seipp authored
      This includes pretty much all the changes needed to make `Applicative`
      a superclass of `Monad` finally. There's mostly reshuffling in the
      interests of avoid orphans and boot files, but luckily we can resolve
      all of them, pretty much. The only catch was that
      Alternative/MonadPlus also had to go into Prelude to avoid this.
      As a result, we must update the hsc2hs and haddock submodules.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      Test Plan: Build things, they might not explode horribly.
      Reviewers: hvr, simonmar
      Subscribers: simonmar
      Differential Revision: https://phabricator.haskell.org/D13
  11. 06 Sep, 2014 2 commits
  12. 05 Sep, 2014 1 commit
  13. 04 Sep, 2014 3 commits
  14. 02 Sep, 2014 1 commit
  15. 01 Sep, 2014 2 commits
  16. 29 Aug, 2014 1 commit
    • Simon Peyton Jones's avatar
      Performance improvement of the compiler itself · 5da580be
      Simon Peyton Jones authored
      This is a result of one of these, or a combination
        002b7a2b * Give the worker for an INLINABLE function a suitably-phased Activation
        ca666b8b * When finding loop breakers, distinguish INLINE from INLINEABLE
        a98c9c5e * Fix a bug in CSE, for INLINE/INLNEABLE things
      Some changes are quite big: for bytes_allocated we have
        T6048: 13% below expected
        T5837: 15% below expected
        T3064:  5% below expected
      Of course, these might have already been close to their lower
      threshold, so perhaps not all the improvement is from here.
      But it is good news all the same.
  17. 08 Aug, 2014 1 commit
  18. 07 Aug, 2014 1 commit
    • Edward Z. Yang's avatar
      Permanently accept the Haddock performance number bump, and add some TODOs · d026e9e8
      Edward Z. Yang authored
      I bisected the performance difference in Haddock and found it was due to
      d6aec63c009c4e57181900eb03847d7dc0fc3c7c, which I accidentally picked up
      when updating Haddock 00b8f8c5
      .  The
      performance regression is justified by the fact that we are now actually
      processing URLs in Haddock comments that we were not previously, so
      there would be more allocation.  Time use was not affected.
      The TODOs simply reflect the fact that we need updated numbers for
      32-bit Linux and Windows.  Please add them when you get a chance.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
  19. 05 Aug, 2014 1 commit
  20. 01 Aug, 2014 1 commit
    • Joachim Breitner's avatar
      Bump haddock.base max_bytes_used · 8df7fea7
      Joachim Breitner authored
      It has reliably increased with commit 1ae5fa45, and has been stable
      since then, so it does not seem to be a fluke. I did not investigate why
      that commit might have increased this value.
  21. 17 Jul, 2014 1 commit
    • Joachim Breitner's avatar
      Adjust a few performance numbers · 13cb4c27
      Joachim Breitner authored
      These did not yet trigger a failure, but are more than 1% away from the
      expected value. Since I now start collecting logs to investigate
      deviations from the expected value, it makes sense to reset them. This
      way we know that every significat deviation was caused since this
      I only updated bytes_allocated numbers, as these are (mostly)
      deterministic. Other depend, AFAIK, on sampling timing, so I did not
  22. 14 Jul, 2014 1 commit
  23. 29 Jun, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Update 32bit & 64bit performance numbers · f12075d3
      Herbert Valerio Riedel authored
      Some numbers have decreased but the haddock numbers have generally
      increased noticeable again (see also last update in 970e5d99)
      This updates all numbers I noticed in the "fast" test-mode, *except* for
      the T9203 test-case on 32bit, which needs more investigation before
      bumping due to its significant increase:
        bytes allocated value is too high:
            Expected    bytes allocated: 50000000 +/-5%
            Lower bound bytes allocated: 47500000
            Upper bound bytes allocated: 52500000
            Actual      bytes allocated: 85093548
        *** unexpected failure for T9203(normal)
  24. 12 Jun, 2014 1 commit
  25. 28 Apr, 2014 1 commit
  26. 07 Apr, 2014 1 commit
  27. 28 Jan, 2014 1 commit
    • Austin Seipp's avatar
      Update some mingw32 perf numbers. · db9baf08
      Austin Seipp authored
      I forgot to push these from my win32 machine. A lot of them actually
      look like a result of Herbert doing his GMP work, which might slightly
      affect allocations on platforms like Windows (where we always use
      in-tree GMP - but presumably Windows allocations could fluxuate slightly
      due to minute details in the GMP implementation, too.)
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
  28. 23 Jan, 2014 1 commit
  29. 22 Jan, 2014 1 commit
  30. 14 Jan, 2014 1 commit
  31. 12 Jan, 2014 1 commit
  32. 28 Dec, 2013 1 commit
  33. 12 Dec, 2013 1 commit