Specialized pattern compilation for enum tags #1846
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The recent introduction of full pattern matching incurred a performance regression for very large enum contracts. Indeed, previously enum-only pattern matching would directly index into a hashmap of the branches of the pattern - where the key is the enum tag which is the pattern associated with the branch -, giving amortized constant time. The more powerful and generic pattern matching introduced later instead compiles each pattern to a (potentially complex) booleanc check. This is necessary in general, but for match statements that are just composed of bare enum tags, this trade a constant time operation for a linear (in the number of branches). This shown important regressions on some code bases making heavy usage of very large enum types/contracts. This commit specializes the compilation of match expressions when all the patterns are enum tags to recover the old behavior. We just reuse the unary operator `%match%`, which was precisely used to implement the old pattern matching, and was just standing there unused since the introduction of the new match expression compilation.
vkleen
approved these changes
Mar 11, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The recent introduction of full pattern matching incurred a big performance regression for very large enum contracts (initially reported by @Quantum64).
Indeed, previously enum-only pattern matching would directly index into a hashmap of the branches of the pattern - where the key is the enum tag which is the pattern associated with the branch -, giving amortized constant time.
The more powerful and generic pattern matching introduced later instead compiles each pattern to a (potentially complex) boolean check. This is necessary in general, but for match statements that are just composed of bare enum tags, this trades a constant time operation for a linear one (in the number of branches). This has shown important regressions on specific code bases making heavy usage of very large enum contracts.
This commit specializes the compilation of match expressions when all the patterns are enum tags to recover the old behavior. We just reuse the unary operator
%match%, which was precisely used to implement the old pattern matching, and was just standing there unused since the introduction of the new match expression compilation.This recovers the same performance as 1.4.1, tested locally, on the offending codebases.
Future work
We could actually extend this optimization, without a lot of effort, to match expressions where patterns are enums in general (and not only enum tags). We would index in the hashmap by enum tag, and only then perform the potentital remaining cheap checks to distinguish bewteen
'Fooand'Foo x. This is left for future work.