-
Notifications
You must be signed in to change notification settings - Fork 219
Partially fix whitespace parsing performance regression #1512
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
Conversation
This undoes some of the performance regression introduced in #1483 Before #1483: ``` benchmarked Line comment time 11.86 ms (11.69 ms .. 11.98 ms) 0.999 R² (0.999 R² .. 1.000 R²) mean 11.84 ms (11.79 ms .. 11.89 ms) std dev 129.4 μs (107.2 μs .. 164.1 μs) benchmarked Block comment time 13.20 ms (13.00 ms .. 13.41 ms) 0.999 R² (0.998 R² .. 1.000 R²) mean 13.59 ms (13.41 ms .. 13.94 ms) std dev 600.0 μs (142.2 μs .. 953.7 μs) ``` After #1483: ``` benchmarked Line comment time 288.7 ms (282.8 ms .. 294.7 ms) 1.000 R² (0.999 R² .. 1.000 R²) mean 292.3 ms (290.8 ms .. 294.6 ms) std dev 3.156 ms (2.216 ms .. 4.546 ms) benchmarked Block comment time 286.2 ms (280.9 ms .. 292.6 ms) 0.999 R² (0.998 R² .. 1.000 R²) mean 290.6 ms (288.3 ms .. 292.9 ms) std dev 3.875 ms (2.866 ms .. 5.500 ms) ``` After this change: ``` benchmarked Line comment time 61.44 ms (60.37 ms .. 63.03 ms) 0.999 R² (0.997 R² .. 1.000 R²) mean 61.41 ms (60.74 ms .. 62.25 ms) std dev 1.341 ms (945.0 μs .. 1.901 ms) benchmarked Block comment time 61.83 ms (60.97 ms .. 63.14 ms) 0.999 R² (0.998 R² .. 1.000 R²) mean 61.16 ms (60.33 ms .. 61.85 ms) std dev 1.396 ms (1.011 ms .. 1.907 ms) ```
This is about as fast as I can get with simple changes. Getting fully back to the original performance would require much more invasive fixes, but I think this is probably good enough. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Impressive!
@@ -262,14 +262,14 @@ parsers embedded = Parsers {..} | |||
a <- operatorExpression | |||
|
|||
let alternative4A = do | |||
try (whitespace *> _arrow) | |||
_arrow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, that's smart! 👍
@@ -108,10 +109,14 @@ notesInLetInLet = do | |||
(Just " ") | |||
Nothing | |||
(Just " ") | |||
(Note "2" (NaturalLit 2)) | |||
(Note "2 " (Note "2" (NaturalLit 2))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where do the additional Note
s come from?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The two Note
s were actually always there, but they used to have the same source span so they would be flattened into one Note
by this logic:
dhall-haskell/dhall/src/Dhall/Parser/Expression.hs
Lines 91 to 93 in 7eec31d
case e of | |
Note src₁ _ | laxSrcEq src₀ src₁ -> return e | |
_ -> return (Note src₀ e) |
Now that they slightly differ they are no longer flattened in this way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we could change that rule to always return the inner Note
– not sure whether that would be beneficial though…
This undoes some of the performance regression introduced
in #1483
Before #1483:
After #1483:
After this change: