Compilation time

Robin Palotai palotai.robin at gmail.com
Tue Jul 4 07:29:12 UTC 2017


Note that Travis CI time is a sum of all operations, including
fetching/saving caches etc.

Opening the build log and looking for the compilation might be more
revealing. For example, 7.10 seems ~10 seconds, 8.2.1 seems ~50 seconds.

There are two issues I can see with this, that should be addressed by
benchmarking:

1) The Travis CI build hosts might show varying performance across reruns
due to shared machines.

2) Tuning the RTS params when invoking GHC as a compiler can yield
significant benefits, at least on larger compilations (such as -A128m).

It would probably be doable to fetch a set of packages from *ackage and
build with various compilers under controlled circumstances?

Robin

2017-07-04 9:16 GMT+02:00 Deest, Gaël <gael.deest at tweag.io>:

> Hi all,
>
> As you are probably well aware, GHC performance has been a growing concern
> over the last few years. Many Haskell programmers complain that build time
> has significantly increased over the last few releases. However, to our
> knowledge, there isn't much data available to substantiate this claim and
> the severity of these problems is not well known.
>
> That's why we would like to bring some anecdotal evidence to your
> attention that seems to indicate really major performance regressions. We
> stumbled upon the CI of the data-reify package, which is built against all
> GHC releases since 2010 :
>
> https://travis-ci.org/ku-fpg/data-reify
>
> tl;dr: Build time has gone from 1 min 32s for GHC 7.0 to 4 min 35s for GHC
> 8.2. The 8.2 release alone seems to have increased compilation time by
> almost 2 minutes, with the current development branch bringing only minor
> performance improvements.
>
> Of course, this single data point is not sufficient to establish how
> severe and widespread these problems are. More data could probably be
> gathered from other packages. However, it certainly matches our
> (subjective) experience and we felt important to report it to you.
>
> Regards,
>
> --
> Gaël Deest
> Tweag I/O
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170704/675b49d4/attachment.html>


More information about the ghc-devs mailing list