GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-10-19T08:50:33Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15304Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.22021-10-19T08:50:33ZNathanWaivioHuge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2I am the author of the cl3 library on Hackage. I have noticed a huge increase of compile time and memory use when testing 8.2.2 and 8.4.2. ghc-8.0.2 compiled in 4:17.33 using 3.5 GB. ghc-8.2.2 compiled in 26:40.15 using 32.8 GB. This is ...I am the author of the cl3 library on Hackage. I have noticed a huge increase of compile time and memory use when testing 8.2.2 and 8.4.2. ghc-8.0.2 compiled in 4:17.33 using 3.5 GB. ghc-8.2.2 compiled in 26:40.15 using 32.8 GB. This is an increase of 6x in time and 9x in memory. This is not all bad, my nbody benchmark has improved about 35% between ghc-8.0.2 and ghc-8.4.2 so the increased compilation time and memory usage are producing much better runtime performance. I am interested if you could suggest some workarounds to help others compile on systems with less resources. I have 64GB memory in my system and would like to test out some -fno-\* GHC Options. Could you point me in the right direction? The library is almost entirely pure functions. I am also interested in other options, like if there are ways to rewrite things to make it easier on the compiler or using NOINLINE on a trouble spot and how to find that trouble spot.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I am the author of the cl3 library on Hackage. I have noticed a huge increase of compile time and memory use when testing 8.2.2 and 8.4.2. ghc-8.0.2 compiled in 4:17.33 using 3.5 GB. ghc-8.2.2 compiled in 26:40.15 using 32.8 GB. This is an increase of 6x in time and 9x in memory. This is not all bad, my nbody benchmark has improved about 35% between ghc-8.0.2 and ghc-8.4.2 so the increased compilation time and memory usage are producing much better runtime performance. I am interested if you could suggest some workarounds to help others compile on systems with less resources. I have 64GB memory in my system and would like to test out some -fno-* GHC Options. Could you point me in the right direction? The library is almost entirely pure functions. I am also interested in other options, like if there are ways to rewrite things to make it easier on the compiler or using NOINLINE on a trouble spot and how to find that trouble spot.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/15229Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc2019-07-07T18:13:42ZMatthew PickeringRun typeCheckResultAction and renamedResultAction in TcM rather than HscThe primary motivation for this is that this allows users to access
the warnings and error machinery present in TcM. However, it also allows
users to use TcM actions which means they can typecheck GhcPs which
could be significantly easie...The primary motivation for this is that this allows users to access
the warnings and error machinery present in TcM. However, it also allows
users to use TcM actions which means they can typecheck GhcPs which
could be significantly easier than constructing GhcTc.
See https://phabricator.haskell.org/D4792
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["plugins"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The primary motivation for this is that this allows users to access\r\nthe warnings and error machinery present in TcM. However, it also allows\r\nusers to use TcM actions which means they can typecheck GhcPs which\r\ncould be significantly easier than constructing GhcTc.\r\n\r\nSee https://phabricator.haskell.org/D4792","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/13240Make it easier to find builds we may want to cancel2019-07-07T18:22:58ZDavid FeuerMake it easier to find builds we may want to cancelI'd love to have a relatively easy way to hunt down and abort Harbormaster builds that aren't very useful, and perhaps to avoid some obviously wasteful builds. Examples:
1. Someone pushed several versions of a single differential, and i...I'd love to have a relatively easy way to hunt down and abort Harbormaster builds that aren't very useful, and perhaps to avoid some obviously wasteful builds. Examples:
1. Someone pushed several versions of a single differential, and it seems clear that only the most recent version is likely to be of interest.
1. A build for a different architecture/OS has failed for a reason that seems obviously non-platform-specific.
1. Only documentation files have changed. Building these on one platform should be sufficient.
1. A differential was closed by a commit. Only the most recent build will be useful, if that.
It would also be nice to get a list of build jobs waiting for specific platforms. These days, for example, we seem to have a lot more demand than supply for OSX bots. If we could get a list of all pending OSX builds, we could look through them by hand and see if any should be canceled.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Trac & Git |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make it easier to find builds we may want to cancel","status":"New","operating_system":"","component":"Trac & Git","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"mpickering"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I'd love to have a relatively easy way to hunt down and abort Harbormaster builds that aren't very useful, and perhaps to avoid some obviously wasteful builds. Examples:\r\n\r\n1. Someone pushed several versions of a single differential, and it seems clear that only the most recent version is likely to be of interest.\r\n\r\n2. A build for a different architecture/OS has failed for a reason that seems obviously non-platform-specific.\r\n\r\n3. Only documentation files have changed. Building these on one platform should be sufficient.\r\n\r\n4. A differential was closed by a commit. Only the most recent build will be useful, if that.\r\n\r\nIt would also be nice to get a list of build jobs waiting for specific platforms. These days, for example, we seem to have a lot more demand than supply for OSX bots. If we could get a list of all pending OSX builds, we could look through them by hand and see if any should be canceled.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Matthew PickeringMatthew Pickering