This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 11 Oct, 2016 1 commit
  2. 04 Oct, 2016 2 commits
  3. 02 Oct, 2016 2 commits
    • Herbert Valerio Riedel's avatar
      Optimise `Ord Version` instance · aabee7c3
      Herbert Valerio Riedel authored
      Profiling showed that there are quite a few 'Ord' calls (~70k calls)
      which result in 'versionNumbers' being evaluated because the need to
      compare with Versions not fitting in a Word64 becomes necessary, mostly
      when inserting into a `Map`. So I've optimised this a bit more.  After
      some experimentation, the new `compare` implemetation results in faster
      comparisions (`cmpOpt` is the new optimised impl, `compare` is the
      previous naive one):
      
      comparing two PV1 constructors:
      
          benchmarking compare 1.2.3.4.5 1.2.3.4.5
          time                 42.33 ns   (42.17 ns .. 42.47 ns)
                               1.000 R²   (1.000 R² .. 1.000 R²)
          mean                 42.17 ns   (42.13 ns .. 42.28 ns)
          std dev              205.1 ps   (128.7 ps .. 325.7 ps)
      
          benchmarking cmpOpt  1.2.3.4.5 1.2.3.4.5
          time                 33.31 ns   (33.23 ns .. 33.40 ns)
                               1.000 R²   (1.000 R² .. 1.000 R²)
          mean                 33.37 ns   (33.29 ns .. 33.46 ns)
          std dev              288.6 ps   (242.9 ps .. 315.8 ps)
      
          benchmarking compare [1.2.3.4.5] [1.2.3.4.5]
          time                 31.92 ns   (31.89 ns .. 31.94 ns)
                               1.000 R²   (1.000 R² .. 1.000 R²)
          mean                 31.89 ns   (31.88 ns .. 31.91 ns)
          std dev              37.09 ps   (24.38 ps .. 54.82 ps)
      
      comparing a PV0 constructor with a PV1 constructor when the first digit
      decides the outcome:
      
          benchmarking compare 2.3.4 1.2.3.4.5
          time                 24.96 ns   (24.78 ns .. 25.25 ns)
                               0.996 R²   (0.989 R² .. 1.000 R²)
          mean                 25.50 ns   (24.95 ns .. 26.95 ns)
          std dev              2.802 ns   (1.275 ns .. 5.163 ns)
          variance introduced by outliers: 93% (severely inflated)
      
          benchmarking cmpOpt  2.3.4 1.2.3.4.5
          time                 11.29 ns   (11.27 ns .. 11.30 ns)
                               1.000 R²   (1.000 R² .. 1.000 R²)
          mean                 11.28 ns   (11.27 ns .. 11.29 ns)
          std dev              24.69 ps   (12.02 ps .. 46.86 ps)
      
          benchmarking compare [2.3.4] [1.2.3.4.5]
          time                 11.05 ns   (11.04 ns .. 11.06 ns)
                               1.000 R²   (1.000 R² .. 1.000 R²)
          mean                 11.05 ns   (11.04 ns .. 11.06 ns)
          std dev              32.82 ps   (15.89 ps .. 61.64 ps)
      
      These timings are now very close to the 'Ord [Int]' timings.
      
      With this optimisation, the total number of 'versionNumbers' calls
      reported by `+RTS -p` for `cabal new-build --dry`'ing haskell-ide-engine
      went down from originally 73501 calls to 6789 calls.
      aabee7c3
    • Herbert Valerio Riedel's avatar
      Optimise `Version` representation · cbddd8cb
      Herbert Valerio Riedel authored
      This optimises the `[Int]` representation to a 16-byte heap object for
      ~99% of version numbers (up to 4 components, each within a [0..0xfffe]
      value range) occuring on Hackage.
      
      One noteworthy improvement of this optimisation is a significant reduction
      of the size of the 01-index.cache file from previously 6299700 bytes
      (before #3905) down to 3408864 bytes, i.e. down to ~54%
      
      Also, this reduces the memory footprint and GC overhead a bit for
      e.g. `cabal info zzz` (which reads in the index cache) from
      
          cabal.0: There is no package named 'zzz'.
          You may need to run 'cabal update' to get the latest list of available
          packages.
               859,337,368 bytes allocated in the heap
               447,261,128 bytes copied during GC
                37,385,208 bytes maximum residency (19 sample(s))
                 1,311,136 bytes maximum slop
                       103 MB total memory in use (0 MB lost due to fragmentation)
      
                                               Tot time (elapsed)  Avg pause  Max pause
            Gen  0      1613 colls,     0 par    0.268s   0.268s     0.0002s    0.0012s
            Gen  1        19 colls,     0 par    0.227s   0.227s     0.0119s    0.0506s
      
            TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1)
      
            SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
      
            INIT    time    0.001s  (  0.001s elapsed)
            MUT     time    0.431s  (  0.758s elapsed)
            GC      time    0.495s  (  0.495s elapsed)
            EXIT    time    0.006s  (  0.005s elapsed)
            Total   time    0.934s  (  1.259s elapsed)
      
            Alloc rate    1,991,870,623 bytes per MUT second
      
            Productivity  46.9% of total user, 34.8% of total elapsed
      
      to
      
          cabal.1: There is no package named 'zzz'.
          You may need to run 'cabal update' to get the latest list of available
          packages.
               834,314,392 bytes allocated in the heap
               440,791,176 bytes copied during GC
                36,663,112 bytes maximum residency (19 sample(s))
                 2,225,040 bytes maximum slop
                        96 MB total memory in use (0 MB lost due to fragmentation)
      
                                               Tot time (elapsed)  Avg pause  Max pause
            Gen  0      1574 colls,     0 par    0.254s   0.254s     0.0002s    0.0007s
            Gen  1        19 colls,     0 par    0.223s   0.223s     0.0118s    0.0474s
      
            TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1)
      
            SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
      
            INIT    time    0.001s  (  0.001s elapsed)
            MUT     time    0.383s  (  0.699s elapsed)
            GC      time    0.477s  (  0.477s elapsed)
            EXIT    time    0.005s  (  0.005s elapsed)
            Total   time    0.869s  (  1.182s elapsed)
      
            Alloc rate    2,175,866,164 bytes per MUT second
      
            Productivity  44.9% of total user, 33.0% of total elapsed
      cbddd8cb
  4. 28 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Make `Version` type opaque (#3905) · bb2026c4
      Herbert Valerio Riedel authored
      Similiar to dabd9d98 which made
      `PackageName` opaque, this makes `Distribution.Version.Version` opaque.
      
      The most common version numbers occuring on Hackage are 3- and
      4-part versions. This results in significant Heap overhead due to
      `Data.Version`'s inefficient internal representation.
      
      So like the `PackageName` commit, this commit is a preparatory commit to
      pave the way for replacing `Version`'s internal representation by a
      representation with a memory footprint which can be an order of
      magnitude smaller.
      
      Finally, this also adds a new functor-like convenience function
      
          alterVersion :: ([Int] -> [Int]) -> Version -> Version
      
      for modifying the version number components.
      bb2026c4
  5. 20 Sep, 2016 1 commit
  6. 05 Sep, 2016 1 commit
    • novadenizen's avatar
      Added TODO: eradicateNoParse comments to all uses of bare 'read' · 978ca74e
      novadenizen authored
      When 'read' is used on invalid input, it raises a "no parse" exception that is
      typically very unhelpful to the user.  It is generally more desirable to either
      handle the error or produce a more helpful error message.
      
      This actually happens sometimes.  When a user creates a detailed-0.9 test
      suite, and that test suite crashes or is killed so it can't write its result
      log, the bare read in Distribution.Simple.Test.LibV09.runTest fails and cabal
      fails with "no parse".
      
      I could have just written a patch to fix that, but it seemed like a better idea
      to find all uses of bare read and see what we can do for all of them.
      
      I have grepped through the repository and I think I've found all uses of bare
      'read' that might raise the dreaded 'no parse' exception.  The plan is to
      separately patch each of them by either replacing with an alternate Read
      function (readMaybe is the most obvious candidate), proving the read will
      always succeed, or establishing that producing a 'no parse' exception is the
      most desirable behavior.
      978ca74e
  7. 01 Sep, 2016 1 commit
  8. 26 Jul, 2016 1 commit
  9. 23 Jul, 2016 1 commit
  10. 21 Jul, 2016 1 commit
  11. 05 Jul, 2016 1 commit
  12. 01 Feb, 2016 1 commit
  13. 31 Jan, 2016 1 commit
  14. 30 Jan, 2016 1 commit
  15. 25 Jan, 2016 1 commit
  16. 14 Jan, 2016 1 commit
  17. 08 Jan, 2016 1 commit
    • Edward Z. Yang's avatar
      Remove same-package import lists, fixes #2835. · 639cd007
      Edward Z. Yang authored
      
      
      Instead of qualifying, in some cases I just added an extra
      'hiding' pragma to squelch errors.  Common conflicts
      (just grep for hiding):
      
          - Flag
              - Distribution.Simple.Compiler
              - Distribution.PackageDescription
              - Distribution.Simple.Setup
          - installedComponentId
              - Distribution.Package
              - Distribution.InstalledPackageInfo
          - doesFileExist
              - Distribution.PackageDescription.Check
          - instantiatedWith
              - I renamed the field in InstalledPackageInfo.  But
                it's probably going away with Backpack bits; I
                migth just excise it soon.
          - absoluteInstallDirs and substPathTemplate
              - Distribution.Simple.InstallDirs
              - Distribution.Simple.LocalBuildInfo
      
      I fixed some shadowing errors by renaming local variables in some cases.
      Common shadowings (we should perhaps consider not using these as
      method/field names):
      
          - freeVars
          - components
          - noVersion
          - verbosity
          - get
          - description
          - name
      
      Some data structures were moved around (IPIConvert and ABIHash)
      to make it easier to handle import lists.
      
      Some functions in Utils could be turned into reexports of standard
      library functions.
      
      No explicit imports were removed from non-Cabal imports.  These
      imports help maintain warning cleanliness across versions of GHC,
      so I don't recommend removing them.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      639cd007
  18. 24 Dec, 2015 1 commit
  19. 13 Nov, 2015 1 commit
  20. 12 Nov, 2015 1 commit
  21. 22 Sep, 2015 1 commit
  22. 20 Sep, 2015 2 commits
  23. 06 Jun, 2015 1 commit
  24. 04 Jun, 2015 2 commits
  25. 08 Jan, 2015 1 commit
    • ttuegel's avatar
      D.Compat.Binary: backport binary generics to binary-0.5 · c650e347
      ttuegel authored
      GHC generics are used to derive binary instances for types appearing
      in the persistent build config, which requires GHC >= 7.2 and
      binary >= 0.7. Unfortunately, GHC < 7.8 ships with binary == 0.5.*.
      The missing module is Data.Binary.Generics, which we have copied from
      binary-0.7.2.3 to Distribution.Compat.Binary.Generics. To provide
      generic implementations for the Binary class, we also have to provide
      our own implementation, which is copied from binary-0.7.2.3 to
      Distribution.Compat.Binary.Class. The interface required by Cabal is
      exported from Distribution.Compat.Binary. This is only done if
      bootstrapping Cabal with GHC < 7.8 or if binary >= 0.7 is not available,
      otherwise Distribution.Compat.Binary simply re-exports Data.Binary.
      c650e347
  26. 29 Oct, 2014 1 commit
  27. 21 Oct, 2014 1 commit
  28. 30 Aug, 2014 1 commit
  29. 27 Aug, 2014 1 commit
  30. 14 Apr, 2014 1 commit
  31. 15 Feb, 2014 1 commit
  32. 02 Feb, 2014 1 commit
  33. 06 Dec, 2013 1 commit
  34. 05 Dec, 2013 1 commit
  35. 13 Sep, 2013 1 commit
  36. 09 Sep, 2013 1 commit