-
Notifications
You must be signed in to change notification settings - Fork 441
Reduce usage of currentToken
#1909
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
Reduce usage of currentToken
#1909
Conversation
@swift-ci Please test |
/// In assert builds, this traps if the loop has not made any parser progress in between two iterations, | ||
/// ie. it checks if the parser's `currentToken` has changed in between two calls to `evaluate`. | ||
/// In non-assert builds, `evaluate()` returns `false` if the loop has not made progress, thus aborting the loop. | ||
mutating func evaluate(_ currentToken: Lexer.Lexeme) -> Bool { | ||
mutating func evaluate(_ parser: some TokenConsumer) -> Bool { |
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.
Parser
and Parser.Lookahead
are both structs right? Do we really want to copy that in here on every evaluate
?
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.
Hmm, interesting. I actually just played around with it again and was able to improve performance by 0.5% with a @inline(__always)
entry function. Not entirely sure why, but 🏎️
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.
My preference here would be a Parser
function eg. hasProgressed
that takes a LoopProgressCondition
instead. The latter probably isn't the correct name any more either though 😅
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.
Done. I kept the name as LoopProgressCondition
because I didn’t have a better idea and it does describe what the condition is being used for.
3d0d3d1
to
4418dc6
Compare
@swift-ci Please test |
@swift-ci Please test Windows |
4418dc6
to
0028719
Compare
@swift-ci Please test |
0028719
to
f9982f0
Compare
@swift-ci Please test |
@swift-ci Please test Windows |
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.
PR message is out of date now, but otherwise LGTM
f9982f0
to
526ce24
Compare
@swift-ci Please test |
@swift-ci Please test Windows |
526ce24
to
e85b5d2
Compare
… `Lexeme` This slightly simpifies the call sides.
This improves parsing performance by 1.5%.
e85b5d2
to
0554638
Compare
@swift-ci Please test |
@swift-ci Please test Windows |
The motivation for these changes is to reduce the usage of
Parser.currentToken
because in general theat
primitives should be preferred to checking thecurrentToken
itself. But independent of these motivations, I think the changes simplify the codebase on their own.LoopProgress.evaluate
to take aTokenConsumer
(i.e.Parser
orLookahead
) instead ofcurrentToken
. This shortens the call sides slightlyatStartOfLine
toParser
to shortenself.currentToken.isAtStartOfLine
toself.atStartOfLine
I measured performance and there’s no significant performance regression associated with this change (based on parsing MovieSwiftUI).