Optimize format of type list id strings used in maps#10240
Merged
Merged
Optimize format of type list id strings used in maps#10240
Conversation
Member
|
Almost a kind of run length encoding for IDs. Neat. |
This file contains hidden or 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
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 compiler extensively uses caches to share instantiations of generic types as well as union, intersection, and tuple types. These caches are simply objects where the entries are keyed by property names synthesized from the unique IDs assigned to type objects. Previously we'd construct type cache keys as comma separated lists of type IDs. For example, the union type A | B | C | D would have a key like "1000,1001,1002,1003", where each numeric string is the unique ID of the type. This PR optimizes the key format by encoding two or more consecutive IDs as "xxxx:nnnn", where xxxx is the starting ID and nnnn is the number of IDs. So, the key for A | B | C | D simply becomes "1000:4" if the types have consecutive IDs. Since union types often have constituents with consecutive IDs (particularly union enum types), this can dramatically reduce the length of keys, which helps performance and memory consumption. Informal tests show a 2-3% speedup of the type check phase when compiling the compiler itself.