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 lines. Although I don
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 but then I realised t
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
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 description, Cabal tries to fi
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 the pre-process phase. There work in
>> pro
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, 60 modules) Haskell project I
>> have layi
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 a little while, during t
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 https://ghc.haskell.org/trac/ghc/ticket/12
On 17 February 2016 at 14:31, Tuncer Ayaz wrote:
> 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
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 around takes over 5 seconds
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, e.g. long list literals.
>> There are probab
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, it
Here's a thought: has anyone experience with limiting a certain major
release to just bug fixes and perf regression fixes, while postponing
all feature patches? It sounds like a good idea on paper, but has
anyone seen it work, and would this be something to consider for GHC?
I'm not suggesting the
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 tickets for these.
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 bette
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,
> you can't build with it anymore until those
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 packages are updated,
which won
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 libraries and
>> these projec
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 appears extremely unfortun
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 ought to be
> discussed he
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
_
21 matches
Mail list logo