-
Notifications
You must be signed in to change notification settings - Fork 211
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
Improve performance of type-checking record literals #1048
Conversation
While benchmarking the example from #769 I saw that a significant amount of time was spent benchmarking record literals. When I looked at the code more closely I saw that the first key in the record literal was being type-checked twice (once to figure out the record's associated type-checking constant and once as part of the `process` loop). This change fixes that, which speeds up interpretation of the large example by 9%: Before: ``` time 18.13 s (18.11 s .. 18.16 s) 1.000 R² (1.000 R² .. 1.000 R²) mean 18.09 s (18.07 s .. 18.11 s) std dev 21.92 ms (10.66 ms .. 29.76 ms) variance introduced by outliers: 19% (moderately inflated) ``` After: ``` time 16.53 s (16.49 s .. 16.60 s) 1.000 R² (1.000 R² .. 1.000 R²) mean 16.59 s (16.56 s .. 16.64 s) std dev 43.65 ms (6.227 ms .. 56.35 ms) variance introduced by outliers: 19% (moderately inflated) ```
Nice! I'm wondering whether we should try to do the same with dhall-haskell/dhall/src/Dhall/TypeCheck.hs Lines 513 to 547 in 92bdd56
It's a bit more complicated though since |
@sjakobi: I'm going to do that separately, because I want to make sure that I have an example benchmark that shows that the change is an improvement before making the change. |
@Gabriel439 No worries. I doubt that it offers similar performance gains as the |
@sjakobi: Yeah, we can track that in a separate issue |
While benchmarking the example from #769 I saw that a significant
amount of time was spent benchmarking record literals. When I looked
at the code more closely I saw that the first key in the record literal
was being type-checked twice (once to figure out the record's associated
type-checking constant and once as part of the
process
loop).This change fixes that, which speeds up interpretation of the large
example by 9%:
Before:
After:
This also includes a small change to use a new
unorderedTraverseWithKey
utility instead of
traverseWithKey
. This appears to have no effect onperformance, but I did this anyway so that I could be sure that any
slowness in this code is not related to any
Dhall.Map
-specific weirdness.