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

Loading some modules takes longer than expected #544

Closed
ghost opened this issue Aug 7, 2018 · 3 comments
Closed

Loading some modules takes longer than expected #544

ghost opened this issue Aug 7, 2018 · 3 comments
Assignees
Labels
exponential slowdown Extreme performance problems performance General performance related issues.
Milestone

Comments

@ghost
Copy link

ghost commented Aug 7, 2018

This is just a follow up to the conversation I had with @brianhuffman about certain modules (around 2K loc) taking longer than expected. I can provide further details on request.

@brianhuffman
Copy link
Contributor

After looking into this, it seems that the @@ operation to combine Subst values (used for unification of type variables during type checking) becomes a bottleneck when the substitution gets large. I have some ideas for different ways to implement this more efficiently.

@brianhuffman brianhuffman self-assigned this Aug 8, 2018
brianhuffman pushed a commit that referenced this issue Aug 8, 2018
This speeds up the test suite by about 10%, and makes the example
file from issue #544 typecheck about 7x faster.
@brianhuffman
Copy link
Contributor

Switching Subst to use IntMap instead of Map gives a significant constant-factor speedup. However, the asymptotic run-time performance is still bad: at least cubic in the size of the input.

@atomb atomb added this to the 2.6.1 milestone Aug 21, 2018
@atomb atomb modified the milestones: 2.6.1, 2.7.0, 2.8.0 Apr 16, 2019
@atomb atomb modified the milestones: 2.8.0, 2.9.0 Aug 28, 2019
@robdockins robdockins added exponential slowdown Extreme performance problems performance General performance related issues. labels Apr 17, 2020
@brianhuffman
Copy link
Contributor

The problematic input mentioned in the original post was an unusually difficult case, in that it was not only big, but contained a very high number of local declarations inside where blocks. We expect that situations where the Subst values in unification are a performance bottleneck will be quite rare, so we'll close this ticket, at least until it becomes a problem for someone again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exponential slowdown Extreme performance problems performance General performance related issues.
Projects
None yet
Development

No branches or pull requests

3 participants