Use Data.Map.Strict instead of Data.Map#2611
Conversation
|
Not sure why the Hydra build failed. |
@winitzki This shouldn't be related to the code changes, right? |
Right, I believe it has nothing to do with the code changes. All tests passed in this PR. A similar situation is happening right now in another PR: #2513 Most likely it's a stale failed build that Hydra has cached for some reason. Someone needs to restart the server somewhere. |
|
Yeah, this is an issue with Hydra where it sometimes run out of memory and then I log in to manually restart the build. The main reason I still use Hydra is because it ensures that the cache is preserved between builds, which at the time was hard to get with other CI solutions. However, I have been thinking of switching to Garnix for Nix builds, which would fix this problem (I think). |
|
@Gabriella439 there is also |
1.42.2 * [Supports standard version 23.1.0](https://github.com/dhall-lang/dhall-lang/releases/tag/v23.1.0) * [Allow `Natural` and `Integer` literals in binary notation](dhall-lang/dhall-haskell#2540) * Fix macOS build [[#2561](dhall-lang/dhall-haskell#2561)] / [[#2586](dhall-lang/dhall-haskell#2586)] * [`dhall to-directory-tree`: Fix support for empty `Map`s](dhall-lang/dhall-haskell#2609) * [`Dhall.TH`: Improve recompilation checking](dhall-lang/dhall-haskell#2620) * `Dhall.TH` utilities now use `addDependentFile` internally so that GHC will recompile if any Dhall dependencies change * Performance improvements * Optimize `Natural/fold`: [[#2585](dhall-lang/dhall-haskell#2585)] / [[#2596](dhall-lang/dhall-haskell#2596)] * [Improve `Dhall.Map.traverseWithKey` performance](dhall-lang/dhall-haskell#2589) * The fold will now short-circuit if it reaches a fixed point * [#2611](dhall-lang/dhall-haskell#2611) * Fixes and improvements to test suite * [#2593](dhall-lang/dhall-haskell#2593) * Fixes and improvements to haddocks * [#2546](dhall-lang/dhall-haskell#2546) * Fixes and improvements to code formatting * [#2608](dhall-lang/dhall-haskell#2608)
4 participants
When trying to read a 93Mb Dhall file with
inputExprWithSettings(using a small list of subtitutions), Dhall currently crashes due to a spaceleak (presumably). Profiling showed thatDhall.Mapis to blame for the allocations (withtoListbeing the main retainer) and the only way to get this under control was to switch toData.Map.Strict.Is there a specific reason why the lazy
Data.Mapis used in this module? It seems to me that laziness provides no benefit and moving to the strict version is the way to go.Profiling eventlogs (for a smaller file) can be found here: profiling.zip