Add support for profiling rule performance

[kaorun343]

What is the problem you're trying to solve?

I'd like to know which rules takes a lot of time. If a high cost rule isn't beneficial for my application, I can make a decision to remove it from my rulesets. I'd like to use this feature for such cases.

ESLint provides that feature by setting TIMING=1 environment variable. https://eslint.org/docs/latest/extend/custom-rules#profile-rule-performance

What solution would you like to see?

It would be happy to provide the way of profiling rule performance like ESLint.

[ybiquitous]

@kaorun343 Thanks for the proposal. This idea sounds good to me. 👍🏼

Currently, we have a benchmark script using the benchmark package (see also our document):

https://github.com/stylelint/stylelint/blob/81f0b7fd3070f715627d9cbd4efb428b0bb206ee/scripts/benchmark-rule.mjs#L4

I'm against adding a new runtime dependency only for this feature (note: the latest benchmark version was published 7 years ago).

Fortunately, ESLint provides a simple implementation without any dependencies. It uses process.hrtime() for profiling: https://github.com/eslint/eslint/blob/4a88a54aeb456abe94da9f5b3d5472d14b3116f1/lib/linter/timing.js#L134-L147

If such a simple implementation is accepted and there are no other obstacles, I favor this feature.

[jeddy3]

SGTM. I've labelled the issue as ready to implement. Please consider contributing if you have time.

[fpetrakov]

Seems like an interesting issue to solve, and I would like to take it, but the thing is I haven't really touched CLI code yet, and it can take quite a while to figure stuff out. Is there maybe a somewhat similar option to look at?

[ybiquitous]

@fpetrakov We don't use any environment variables (process.env) except for the test use (process.env.NODE_ENV === 'test'). So, I guess we can implement process.env.TIMING with another module file like ESLint.

[github-actions[bot]]

This issue is older than one month. Please ask before opening a pull request, as it may no longer be relevant.