RE: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

Thomas Tuegel writes: > I think what Andrey meant was, the first time we run the pre-processors, > cache the locations of all the files that need to be pre-processed. On > subsequent runs, we only need to check pre-processors the files in the cache. Yes, something along the

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

On Thu, Feb 18, 2016 at 6:43 AM, Herbert Valerio Riedel wrote: > On 2016-02-18 at 13:32:59 +0100, Andrey Mokhov wrote: >> Interesting! In the new Shake-based build system we also need to >> automagically generate .hs files using Alex et al. My first >> implementation was slow

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

On 2016-02-18 at 13:32:59 +0100, Andrey Mokhov wrote: [...] > Interesting! In the new Shake-based build system we also need to > automagically generate .hs files using Alex et al. My first > implementation was slow but then I realised that it is possible to > scan the source tree only once and

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

Thomas Tuegel writes: > > What exactly does the pre-process phase do, anyways? > It runs the appropriate pre-processor (Alex, Happy, c2hs, etc.) for modules > that require it. It's slow because of the way the process is carried out: For > each module in the package

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

On Wed, Feb 17, 2016 at 2:21 PM, Ben Gamari wrote: > Thomas Tuegel writes: >> I have contributed several performance patches to Cabal in the past, >> so I feel somewhat qualified to speak here. The remaining slowness in >> `cabal build` is mostly due to

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

Thomas Tuegel writes: > On Wed, Feb 17, 2016 at 2:58 AM, Ben Gamari wrote: >> Yes, it would be great if someone could step up to look at Cabal's >> performance. Running `cabal build` on an up-to-date tree of a >> moderately-sized (10 kLoC, 8 components,

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

On 17 February 2016 at 15:47, Austin Seipp wrote: > The better approach, I think, might be to section off certain times > in a release period where we only allow such changes. Only for a > month or so, for example, and you're just encouraged to park your > current work for

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

On Wed, Feb 17, 2016 at 2:14 AM, Edward Z. Yang wrote: > Another large culprit for performance is that the fact that ghc --make > must preprocess and parse the header of every local Haskell file: > https://ghc.haskell.org/trac/ghc/ticket/618 (as well > as

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

On Wed, Feb 17, 2016 at 2:58 AM, Ben Gamari wrote: > Yes, it would be great if someone could step up to look at Cabal's > performance. Running `cabal build` on an up-to-date tree of a > moderately-sized (10 kLoC, 8 components, 60 modules) Haskell project I > have laying

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

Tuncer Ayaz writes: > On 17 February 2016 at 07:40, Evan Laforge wrote: > >> My impression from the reddit thread is that three things are going >> on: >> >> 1 - cabal has quite a bit of startup overhead >> 2 - ghc takes a long time on certain inputs,

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

The better approach, I think, might be to section off certain times in a release period where we only allow such changes. Only for a month or so, for example, and you're just encouraged to park your current work for a little while, during that time, and just improve things. The only problem is,

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

On 17 February 2016 at 07:40, Evan Laforge wrote: > My impression from the reddit thread is that three things are going > on: > > 1 - cabal has quite a bit of startup overhead > 2 - ghc takes a long time on certain inputs, e.g. long list literals. > There are probably already

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

Another large culprit for performance is that the fact that ghc --make must preprocess and parse the header of every local Haskell file: https://ghc.haskell.org/trac/ghc/ticket/618 (as well as https://ghc.haskell.org/trac/ghc/ticket/1290). Neil and I have observed that when you use something

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

Evan Laforge writes: > On Wed, Feb 17, 2016 at 4:38 AM, Ben Gamari wrote: >> Multiple modules aren't a problem. It is dependencies on Hackage >> packages that complicate matters. > > I guess the problem is when ghc breaks a bunch of hackage packages, >

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

On Wed, Feb 17, 2016 at 4:38 AM, Ben Gamari wrote: > Multiple modules aren't a problem. It is dependencies on Hackage > packages that complicate matters. I guess the problem is when ghc breaks a bunch of hackage packages, you can't build with it anymore until those

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

Kosyrev Serge <_deepf...@feelingofgreen.ru> writes: > Ben Gamari writes: >> It would be great if we could get users to submit their >> computationally-heavy, toy projects. Unfortunately, the best testcases >> for us are those with no dependencies outside of the core

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

Ben Gamari writes: > It would be great if we could get users to submit their > computationally-heavy, toy projects. Unfortunately, the best testcases > for us are those with no dependencies outside of the core libraries and > these projects aren't terribly common. This

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

Manuel M T Chakravarty writes: > There is currently an interesting discussion on Reddit on GHC compile > times > > > https://www.reddit.com/r/haskell/comments/45q90s/is_anything_being_done_to_remedy_the_soul/ > > I feel that this is a serious problem; so, it probably

Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

There is currently an interesting discussion on Reddit on GHC compile times https://www.reddit.com/r/haskell/comments/45q90s/is_anything_being_done_to_remedy_the_soul/ I feel that this is a serious problem; so, it probably ought to be discussed here as well. Manuel