Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Data.Map.Strict instead of Data.Map #2611

Merged
merged 2 commits into from
Oct 24, 2024

Conversation

phagenlocher
Copy link
Contributor

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 that Dhall.Map is to blame for the allocations (with toList being the main retainer) and the only way to get this under control was to switch to Data.Map.Strict.

Is there a specific reason why the lazy Data.Map is 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

@winitzki
Copy link
Collaborator

Not sure why the Hydra build failed.

@phagenlocher
Copy link
Contributor Author

Not sure why the Hydra build failed.

@winitzki This shouldn't be related to the code changes, right?

@winitzki
Copy link
Collaborator

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.

@Gabriella439
Copy link
Collaborator

Gabriella439 commented Oct 24, 2024

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 Gabriella439 merged commit 8c3f657 into dhall-lang:main Oct 24, 2024
9 checks passed
@TristanCacqueray
Copy link
Collaborator

@Gabriella439 there is also DeterminateSystems/magic-nix-cache-action@main to keep the cache between GitHub actions, perhaps that would work for Dhall?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants