Any way to profile rule performance?

[s-h-a-d-o-w]

I would love to go through like the 20 slowest rules that I have enabled and check whether I even need them.
Tried profiling like described here but couldn't find anything related to particular rules in the profile: https://oxc.rs/docs/contribute/profiling

[camc314]

Are these rust rules? or Js rules that you want to profile?

[camc314]

I'm confused about the overhead being considered a problem. Even if everything runs ~15% slower during profiling, the relative difference between rules is still meaningful?

The addition of adding timing logic to the code (even when timing was disabled) was significant.

This (at least for me) isn't about figuring out whether some rule is like 3% slower than another. It's about some rules possibly using up like 50% of the overall runtime.

How long is oxlint taking you at the moment? If you've got a repo I can look at, I can profile it and take a look.

[s-h-a-d-o-w]

even when timing was disabled

Oh, what a bummer.

How long is oxlint taking you at the moment? If you've got a repo I can look at, I can profile it and take a look.

That's very nice of you to offer but no worries, the runtime is fine.
I just figured that if I can get an easy win, I'll take it, especially as the project grows or I might use oxlint on larger code bases.

If it ever becomes an actual need, it just occurred to me that I can just write a script that reads all enabled rules from --print-config and then measures runtime for them individually. Should be simple.

[s-h-a-d-o-w]

I actually tried to do this and it doesn't seem feasible - too much variance across runs. Tried a confidence interval window algorithm with up to 40 samples per rule.

Although - as I was working on this, the following rules always clearly seemed to be a the top by some margin, so it's probably safe to say that they take the longest:

typescript/no-unsafe-return
typescript/no-unnecessary-condition
typescript/no-unsafe-argument
typescript/no-unsafe-call
typescript/unbound-method
typescript/no-floating-promises
typescript/no-unsafe-assignment

Note that I didn't evaluate the following at all though:

    "typescript/consistent-return": "off",
    "typescript/dot-notation": "off",
    "typescript/explicit-function-return-type": "off",
    "typescript/explicit-module-boundary-types": "off",
    "typescript/no-confusing-void-expression": "off",
    "typescript/no-non-null-assertion": "off",
    "typescript/prefer-readonly-parameter-types": "off",
    "typescript/promise-function-async": "off",
    "typescript/strict-boolean-expressions": "off",
    "typescript/strict-void-return": "off",
    "typescript/use-unknown-in-catch-callback-variable": "off",

[camc314]

typescript/no-unsafe-return
typescript/no-unnecessary-condition
typescript/no-unsafe-argument
typescript/no-unsafe-call
typescript/unbound-method
typescript/no-floating-promises
typescript/no-unsafe-assignment

yeah these are all type aware so are going to be slow

[s-h-a-d-o-w]

But it's only like 25% of all typeaware rules that I had enabled, so it doesn't seem to be the case that all type aware rules are slow.

You of course know the internals and maybe 75% weren't slow in my case because they weren't triggered as much as the others?
And that's why it would've been nice if this would've worked. At least based on what I've read about your performance optimization in the docs, it's essential how often a rule actually has to run based on the context. You could have 50 really slow rules enabled - if your codebase never triggers them, it won't matter (if I understand things correctly). And so particularly in different large code bases, I would guess that different rules would stand out.