-
-
Notifications
You must be signed in to change notification settings - Fork 477
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
feat(linter): support shared rule state in ctx
#5770
Conversation
Your org has enabled the Graphite merge queue for merging into mainAdd the label “0-merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix. You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link. |
How about this? @Boshen |
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'm not sure if this is going to work, can you continue prototyping by collecting state in run
, and then inspect the state in run_once
moved to the end? We probably need to implement this prototype with two rules.
I'd imagine the states need to be isolated, rule A cannot read data from rule B.
9b8f913
to
c904595
Compare
CodSpeed Performance ReportMerging #5770 will not alter performanceComparing Summary
|
Let me reconsider, it seems like it's not feasible and a bit difficult. 😩 |
I've got some ideas on how to implement this. I'll take a closer look tomorrow. |
> Related to #5770 ## What This PR Does Moves state that is constant over a linted file out of `LintContext` and into a shared `ContextHost` struct, turning `LintContext` into a [flyweight](https://en.wikipedia.org/wiki/Flyweight_pattern). This brings `LintContext` from 144 bytes down to 96. `Linter::run` iterates over `(rule, ctx)` pairs in a very tight loop, and each rule instance gets its own clone of `ctx`. A smaller `LintContext` means better cache locality and a smaller heap allocation for this vec. I'm hoping to eventually get it small enough to fit in a single cache line. I made a PR a while ago that did something similar to this one, but instead of using an `Rc`, each `LintContext` stored a read-only reference. This added an extra lifetime parameter, making it slightly unwieldy, but I saw up to 15%/25% perf improvements on local benchmarks. I'll dig around for it and add a link shortly. ### Architecture ![image](https://github.com/user-attachments/assets/9e8352ae-a581-46a3-a578-9eb855d4ebaf) ---- ![image](https://github.com/user-attachments/assets/49213cd9-3c31-40dc-97ad-ddf010705ab6)
Related to #5204