8

Hello Haskellers out there!

I have the feeling that questions on performance arise more often and that the knowledge on which functions/algorithms/libraries are fast and stable is sparse.

There are of course libraries like Criterion which allow to make measurements on one's own, and there is the profiler which can be invoked by

> ghc -O2 --make program.hs -prof -auto-all
> ./program +RTS -s

as excellently explained by @DonStewart in Tools for analyzing performance of a Haskell program

I know that:

  • the use of read and show is usually a bottleneck (for the read-function in the case of numbers there is the Numeric package which brings a performance speedup
  • and there are the Sequence, Array, Vector and Map libraries, which are often better fit to solve a problem than to use lists or nested lists
  • Text and Bytestring are a better option than String
  • I recently saw that even the use of the standard number generator slows down a program significantly and that mwc-random is a lot faster.
  • Also the answers of Python faster than compiled Haskell? revealed that the standard sorting algorithm is definitely improvable
  • The usage of Int rather than Integer, BangPatterns and strict folds often yield an increase in performance
  • There are conduit and pipes to "stricten" IO, (which I have to admit I haven't used yet)
  • type signatures are general an improvement

What are other common pitfalls and bottlenecks one tends to use?

How to solve those?

The topics that come to my mind are:

  • functions
  • data structures
  • algorithms
  • LANGUAGE extensions (for GHC)?
  • compiler options?
Community
  • 1
  • 1
epsilonhalbe
  • 15,637
  • 5
  • 46
  • 74
  • 2
    "functions, data structures, algorithms, LANGUAGE extensions..." oh, my. I'm afraid this isn't an answerable question, but you can certainly learn lots of the tricks and pitfalls you're looking for by browsing previous questions here on SO. – jberryman Jan 29 '14 at 18:02
  • "Text and Bytestring are a better option than" ... String? – somesoaccount Jan 29 '14 at 18:11
  • I know that all those topics are a bit much and do not expect answer for all of those, but want to give directions that came to my mind. – epsilonhalbe Jan 29 '14 at 18:47
  • 2
    @epsilonhalbe Unfortunately that's not the way you should formulate your question on SO. In the state as it is it stimulates prolonged discussion and makes the scenario of a definite answer highly improbable. Try to break it into specific problems and ask about them in separate threads. – Nikita Volkov Jan 29 '14 at 18:58
  • 2
    High-performance libraries that every Haskell programmer should know: `containers`, `unordered-containers`, `vector`, `attoparsec`, `text`, and `bytestring`. Too bad people closed this topic, otherwise I'd give a longer answer. – Gabriella Gonzalez Jan 30 '14 at 02:26
  • My understanding of conduit and pipes is that they provide a form of controlled laziness rather than strictness. Demand is still very much a driving force, but they do avoid some of the problems with lazy IO. – not my job Jan 30 '14 at 10:17
  • My point is streaming is closer to laziness than it is to strictness, but I've just realised I've said that immediately underneath @GabrielGonzalez's comment, and we should of course defer to his view on this, and pipes in particular. – not my job Jan 30 '14 at 10:23
  • I'd say that `pipes` and `conduit` make it easier to reason about when effects occur compared to lazy IO. Lazy IO ties IO to Haskell's evaluation model, which is more difficult to reason about (both formally and informally). Also, lazy `IO` only works for `IO`, whereas `pipes` and `conduit` work over any monad. – Gabriella Gonzalez Jan 30 '14 at 13:28

0 Answers0