codecov[bot]
commented
1 month ago Codecov Report
Attention: Patch coverage is 91.72932% with 11 lines in your changes are missing coverage. Please review.
Project coverage is 95.64%. Comparing base (
d21bfc7) to head (cfedf60).
| Files | Patch % | Lines |
|---|---|---|
| src/typesystem.rs | 60.00% | 10 Missing :warning: |
| src/validation/statement.rs | 92.85% | 1 Missing :warning: |
Additional details and impacted files
```diff @@ Coverage Diff @@ ## master #1175 +/- ## ========================================== - Coverage 95.67% 95.64% -0.03% ========================================== Files 148 148 Lines 42512 42531 +19 ========================================== + Hits 40673 40680 +7 - Misses 1839 1851 +12 ```:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
volsa
This PR refactors how enum variants are stored in the index, removing the
enum_qualified_variablesentry in the Index and instead storing all enums variants in theDataTypeInformationstruct.Querying enum variants was the main motivation here, as enums are stored unfavorably in the Index currently. Specifically enum variants are stored in an HashMap with their keys being their qualified name, which makes it hard to get all variants of an enum. For example an enum defined in main such as
Color : (red, green, blue)is currently represented as__main_color.red,__main_color.greenand__main_color.bluewhich requires raw string manipulation & comparison degrading performance as described in this issue.Retrieving all variants of an enum in this PR is done by querying for an enum retrieving its datatype, then accessing the
variantsfield which is done in O(1) because we're querying thetype_indexwhich is behind a HashMap. Finding a specific enum variant is still linear however.tl;dr The performance of
plc checkin one of our bigger internal projects is back to 2 seconds (from previously 2-4 minutes)