Slower Compilation on GHC 7.8.4 (vs. 7.6.3)
Ozgun Ataman
ozataman at gmail.com
Tue Apr 14 19:56:00 UTC 2015
Hello all,
Thank you for the comments and apologies that it took a bit of time to get
back to you. My colleague Michael and I have taken a stab at a package
demonstrating the slowdown. Our hypothesis was that the presence of type
declarations, large values/literals, typeclass instantiations and
engagement of TH caused at least some of the slowdown we were seeing in our
app code. It turns out this was only partially true:
- 500 random type declarations were a modest 10-25% slower.
- Simply instantiating types with a given class did not contribute that
much to the slowdown (around 5% on top of type declarations)
- There was no notable slowdown on large values/literals (false
hypothesis)
- TH-enabled derivations were over 100% slower (lens and safecopy used
as test subjects)
- lens: ~100% slower
- safecopy: ~125% slower
- The slowdowns appeared to be super-linear in at least some cases.
Doubling the declaration count to 1000 increased the % of the slowdown:
- Declarations: 30% slower
- lens TH slowdown: ~100% slower (stayed the same)
- safecopy TH slowdown: ~140% slower
I'd be happy to create a ticket if this is sufficient support material.
It's hard to say these conclusively isolate *all* culprits for the full
slowdown we observe in our codebase, but are hopefully at least a
significant part.
Here's the package:
https://dl.dropboxusercontent.com/u/58525/ghc-slowdown.tar.gz
Best,
Oz
On Tue, Apr 7, 2015 at 3:39 PM, Simon Marlow <marlowsd at gmail.com> wrote:
> Just a comment on this one point:
>
> On 05/04/2015 19:01, Ozgun Ataman wrote:
>
>> * With O0 and -j=N the overall wall-clock time is 40% higher, but the
>> CPU time spent is a staggering 7.5X higher (!)
>>
>
> When looking at Haskell programs executing in parallel, it's normal to see
> a high CPU time, because the GC threads spin looking for work. The extra
> CPU time is just time spent spinning, it doesn't imply that the compiler
> was doing extra work. What matters is the overall wall-clock time - a
> worse wall-clock time indicates that something has gone wrong.
>
> We should look at compile-time regression independently of performance
> issues with -j. Parallel compilation is a new feature and mostly likely
> needs a lot of tuning. Note that cabal's -j feature is different from
> GHC's (and is likely to give much more reliable improvements) because it
> runs multiple compiler instances in parallel.
>
> Cheers,
> Simon
>
>
> * With -O0, "cabal repl" load times have gone up by a staggering 2.5X
>> (!)
>> o 7.8.4: 3 min. 35 seconds
>> o 7.6.3: 1 min. 2 seconds
>> * Measuring compile times for individual modules, we see that those
>> that are heavily loaded with lots of types, TH-facilitated type and
>> typeclass derivations and those that contain large "blobs" of values
>> directly at the top level now take much longer to compile:
>> o We have 10 modules that each take over 10 seconds
>> o We have 3 modules that each take over 35 seconds
>> * Sidenote observation: In general, parallel builds with -j appear to
>> cause a very significant overhead under the "system" part of timing:
>> o Example with 7.6.3, O0: cabal build 140.57s user 13.25s system
>> 100% cpu 2:33.70 total
>> o Example with 7.8.4, O0: cabal build 507.83s user 655.43s system
>> 549% cpu 3:31.59 total
>>
>>
>> The main hurt here has been the infeasibility of using "cabal repl /
>> ghci" fast-feedback style development (via emacs, vim, command-line,
>> etc.), since:
>>
>> * Unlike "cabal build", "cabal repl" re-compiles from scratch with
>> every invocation ":l App.Foo.Bar", which itself is the necessary
>> first step when starting to hack on a module (we can then use :r to
>> somewhat help the situation)
>> * The slowdown is about 2.5X as stated above: What used to take a
>> minute now takes 3.5 minutes.
>> * cabal repl does not seem to benefit from -j at all
>> * cabal repl 7.8.4 appears to be hurt particularly by the heavier
>> modules
>> * The heavier modules are often at the top of the compile tree (types,
>> derivations, etc) and are practically loaded on the critical path
>> all the time
>>
>> Let me know if I'm missing anything here and any/all feedback is much
>> appreciated!
>>
>> Cheers,
>> Oz
>>
>>
>> _______________________________________________
>> 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/20150414/64a4f750/attachment-0001.html>
More information about the ghc-devs
mailing list