Opened 2 years ago

Closed 18 months ago

#13639 closed bug (fixed)

Skylighting package compilation is glacial

Reported by: bgamari Owned by: dfeuer
Priority: normal Milestone: 8.6.1
Component: Compiler Version: 8.0.1
Keywords: Cc: mpickering
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by bgamari)

Compiling the skylighting package in profiled and non-profiled configuration takes nearly ten minutes. I haven't looked at the code, but I can't imagine a syntax highlighting package would need to take this long. Investigate.

Attachments (1)

Skylighting.Syntax.Php.hs (159.7 KB) - added by niteria 2 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 2 years ago by bgamari

Description: modified (diff)

comment:2 Changed 2 years ago by dfeuer

Owner: set to dfeuer

I'll take a look and see if I can narrow it down to a module or two. A brief skim of the code didn't show anything too weird, so I'm guessing we're getting a lot of inlining or specialization from dependencies.

comment:3 Changed 2 years ago by dfeuer

Cc: mpickering added

I'm just getting back to looking at this. Since we don't have a record of the problematic skylighting version, let's go with the guess that this is the issue reported as skylighting issue #7. That is, that skylighting-0.1.1.5 compiles slowly. There is further discussion of the problem in texmath issue #96. mpickering was involved in those discussions; I don't know how much he knows/remembers.

Their conclusion was that very large static data can take a long time to compile, for some reason. This whole thing sounds very familiar somehow; wasn't there some recentish work on handling ticks better for long list literals or some such?

The package worked around this problem in Skylighting.Syntax.*: use string representation of the Syntax which simply used read to read a String representation of the data. Later, they switched to Binary.

comment:4 Changed 2 years ago by dfeuer

In a recent HEAD ( 4700baaf8f9bf3c44a53a595d840c7c14cfd6f98 ):

The "nearly ten minutes" seems to be the "user" time in a parallel build, for which the real time is around 3 minutes. If cabal and GHC are each passed -j1, the user time drops to around five minutes. So one issue seems to be some inefficiency in parallel builds. Running single-threaded, I don't see any big difference between the time it takes to build the unprofiled and profiled versions (although of course building both takes about twice as long as building just the unprofiled). So I don't really think profiling has anything to do with the issue, at least for HEAD.

comment:5 Changed 2 years ago by niteria

This package has 123 modules which contain nothing else than a giant multi-kilobyte String. See https://hackage.haskell.org/package/skylighting-0.3.3.1/src/src/Skylighting/Syntax/Jsp.hs for example.

With -g (DWARF) on ghc-8.0.2 it appears to lead to ~40m compile times. I have a strong suspicion that we end up generating debugging information for each of these (:) cells, which is bound to be slow with 4 million of these total and the nesting levels of 10k. I may be wrong because #11095 was supposed to improve it and I'm running with https://git.haskell.org/ghc.git/commitdiff/29122312cc7b8f9890eb53f92d76ecdd8ded24ee already.

I will try to confirm if the problem persists on HEAD.

comment:6 Changed 2 years ago by niteria

Ignore what I said above, it's about a different version of skylighting which doesn't appear to have compile time issues.

comment:7 Changed 2 years ago by niteria

This bisects to a6e13d502ef46de854ec1babcd764ccce68c95e3, meaning that commit fixes the underlying problem. I cherry-picked it onto our ghc-8.0.2-facebook branch and the compile times are reasonable (~2min as opposed to >30m).

I minified the original code to Skylighting.Syntax.Php.hs file that I'm attaching. It's boils down to a large [Text] list. With a commit before the fix there's a big blow up in the term size after one of the simplifier passes. After the fix the term sizes look reasonable.

Relevant part of -dshow-passes (this is the released GHC 8.0.2, but the numbers are the the same before the fix):

!!! Parser [Skylighting.Syntax.Php]: finished in 4556.00 milliseconds, allocated 87.667 megabytes                                                                  [99/1907]
*** Renamer/typechecker [Skylighting.Syntax.Php]:
!!! Renamer/typechecker [Skylighting.Syntax.Php]: finished in 27009.00 milliseconds, allocated 241.752 megabytes
*** Desugar [Skylighting.Syntax.Php]:
Result size of Desugar (after optimization)
  = {terms: 16,197, types: 6,490, coercions: 0}
!!! Desugar [Skylighting.Syntax.Php]: finished in 2024.00 milliseconds, allocated 22.967 megabytes
*** Simplifier [Skylighting.Syntax.Php]:
Result size of Simplifier iteration=1
  = {terms: 22,671, types: 19,426, coercions: 0}
Result size of Simplifier
  = {terms: 22,671, types: 19,426, coercions: 0}
!!! Simplifier [Skylighting.Syntax.Php]: finished in 14080.00 milliseconds, allocated 150.808 megabytes
*** Specialise [Skylighting.Syntax.Php]:
Result size of Specialise
  = {terms: 22,678, types: 19,437, coercions: 2}
!!! Specialise [Skylighting.Syntax.Php]: finished in 5593.00 milliseconds, allocated 32.625 megabytes
*** Float out(FOS {Lam = Just 0,
                   Consts = True,
                   OverSatApps = False}) [Skylighting.Syntax.Php]:
Result size of Float out(FOS {Lam = Just 0,
                              Consts = True,
                              OverSatApps = False})
  = {terms: 48,542, types: 58,233, coercions: 2}
!!! Float out(FOS {Lam = Just 0,
                   Consts = True,
                   OverSatApps = False}) [Skylighting.Syntax.Php]: finished in 8951.00 milliseconds, allocated 126.301 megabytes
*** Simplifier [Skylighting.Syntax.Php]:
Result size of Simplifier iteration=1
  = {terms: 45,307, types: 55,000, coercions: 0}
Result size of Simplifier
  = {terms: 45,307, types: 55,000, coercions: 0}
!!! Simplifier [Skylighting.Syntax.Php]: finished in 36008.00 milliseconds, allocated 394.685 megabytes
*** Simplifier [Skylighting.Syntax.Php]:
Result size of Simplifier iteration=1
  = {terms: 55,006, types: 55,000, coercions: 0}
Result size of Simplifier
  = {terms: 42,074, types: 22,670, coercions: 0}
!!! Simplifier [Skylighting.Syntax.Php]: finished in 44152.00 milliseconds, allocated 564.940 megabytes
*** Simplifier [Skylighting.Syntax.Php]:
Result size of Simplifier iteration=1
  = {terms: 1,060,469, types: 775,959, coercions: 193,980}
Result size of Simplifier iteration=2
  = {terms: 944,081, types: 824,454, coercions: 171,349}
Result size of Simplifier iteration=3
  = {terms: 827,693, types: 624,008, coercions: 38,796}
Result size of Simplifier iteration=4

The slowdown is only when compiling with -prof enabled.

Last edited 2 years ago by niteria (previous) (diff)

Changed 2 years ago by niteria

Attachment: Skylighting.Syntax.Php.hs added

comment:8 Changed 2 years ago by simonpj

meaning that commit fixes the underlying problem.

So can we close this ticket? Or is there still a problem?

comment:9 Changed 20 months ago by bgamari

Milestone: 8.4.18.6.1

This ticket won't be resolved in 8.4; remilestoning for 8.6. Do holler if you are affected by this or would otherwise like to work on it.

comment:10 Changed 18 months ago by bgamari

Resolution: fixed
Status: newclosed

I believe this is resolved.

Note: See TracTickets for help on using tickets.