Closed parsonsmatt closed 2 months ago
@parsonsmatt Great PR, thanks a lot! I have an adajcent question: Have you considered using OsPath instead of FilePath?
Am I misunderstanding the numbers here? It seems like the patch makes things slower overall.
9.4.2 had a bug in eta-expansion which was fixed in 9.4.3 (which affected the Builder
performance).
It is also impossible to review this patch with the current commit history, can you please clean that up if you're going to pursue this.
@Kleidukos I'm not aware of OsPath
and a Stackage search doesn't bring anything up.
@mpickering This PR is based on two other PRs, and when those are merged, this will be much easier to review. While the overall runtime is slightly slower on this case, the benefit is huge for packages that generate large documentation pages - project-specific Prelude
-like modules in particular. Once I get the work app using 9.4.3 or 9.4.4 then I can get a more up-to-date perf numbers.
@Kleidukos I'm not aware of
OsPath
and a Stackage search doesn't bring anything up.
Hoogle is more reliable then, it's a type from https://flora.pm/packages/@haskell/filepath.
Hi, thank you for this PR, but Haddock now lives full-time in the GHC repository! Read more at https://discourse.haskell.org/t/haddock-now-lives-in-the-ghc-repository/9576.
Let me know if you feel it is still needed, and I'll migrate it. :)
I was investigating the weird perf issues with the
Builder
stuff, and noticed that GHC 9.4.2 and GHC 9.4.3 have very different performance characteristics. With GHC 9.4.2,Builder
performs worse. But with GHC 9.4.3, it's significantly better.After thorough investigation, I figured out that part of the issue was materializing all these
[Char]
. Particularly, URLs seemed to be trouble - thexhtml
interface only allowed you to useString
for them, which isn't good. I patchedxhtml
to useLText
for theAttr
, which has a nice balance between performance for concatenation and inspection. This rippled through the code, pushing a ton ofString
intoText
.Additionally, I noticed that we were parsing things using
Parsec
asText
, but thenunpack
ing them into[Char]
. So I pushed theText
through the codebase.This resulted in a pretty nice improvement in peformance. My baseline, using
ghc-9.4
branch:This branch (which does include the #1552 code, too) has these numbers:
23% faster and 18.3% less memory while generating HTML, though the rest of the code is a tiny bit slower.
There's a long way to go towards making HTML generation more efficient. Timing data shows that we allocate roughly 200 times as much memory as the final HTML file weighs - so a ~1.1MB file on disk allocates ~222MB.