#11415 closed bug (fixed)

pandoc-types fails to build on 4 GB machine

Reported by: pavolzetor Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.10.3
Keywords: Generics Cc: gidyn
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: Compile-time performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


I made an attempt to install pandoc on laptop with 4 GB RAM and GHC was killed by OS after using all RAM and swap space (512 MB).

Output from 'emerge pandoc' http://lpaste.net/148881

I can tolerate slow compile times, however this bug makes it impossible to build some packages which is worse.

Change History (9)

comment:1 Changed 21 months ago by pavolzetor

Architecture: Unknown/Multiplex86_64 (amd64)
Operating System: Unknown/MultipleLinux
Type of failure: None/UnknownGHC doesn't work at all

comment:2 Changed 21 months ago by gidyn

Cc: gidyn added

comment:3 Changed 21 months ago by rwbarton

Type of failure: GHC doesn't work at allCompile-time performance bug

comment:4 Changed 21 months ago by mpickering

This isn't about pandoc. The log you paste doesn't get to even trying to install pandoc. I conjecture that the problem is actually that another dependency (maybe texmath) takes up a lot of memory to compile which causes the OOM to appear when compiling pandoc-types which is relatively simple.

comment:5 Changed 21 months ago by rwbarton

Summary: Pandoc fails to build on 4 GB machinepandoc-types fails to build on 4 GB machine

Actually the module Text.Pandoc.Definition is just expensive to build. For me (GHC 7.8.4) it takes about 25 seconds and 460M to build with optimizations. 7.10.1 fares significantly worse, about double on both metrics. (I think it is doing more inlining.)

The main culprit seems to be the FromJSON/ToJSON which use generics. Commenting those out reduces the runtime by a factor of ~5 and the memory usage by a factor of ~3.

comment:6 Changed 21 months ago by simonpj

Keywords: Generics added

comment:7 Changed 21 months ago by pavolzetor

I think it is related to this bug https://github.com/bos/aeson/issues/296.

comment:8 Changed 17 months ago by nh2

See also #11991

comment:9 Changed 16 months ago by thomie

Resolution: fixed
Status: newclosed

In https://github.com/bos/aeson/pull/335#issue-127344930, RyanGlScott mentions:

To test out the improvments, I did a very fast-and-loose profiling of the time and memory it takes to compile pandoc-types (a package known to be affected badly by the aeson-0.10 compilation regressions).

The total wall time went from 10 minutes to under a minute, and it went from using 3 GB of RAM (and thrashing my laptop mercilessly) to about 500 MB of RAM.

pavolzetor: make sure you upgrade to the latest version of aeson to get those improvements.

The real problem with Generics compile-time performance it still tracked in #5642.

Note: See TracTickets for help on using tickets.