Output more rule durations with TIMING environment variable

The version of ESLint you are using.

Latest 7.8.1.

The problem you want to solve.

Context: The per-rule performance numbers outputted by running TIMING=1 eslint are very useful to me, especially because I have a large codebase (thousands of JS files) and hundreds of eslint rules (from eslint core and many plugins) enabled. Running linting takes 5-10 minutes for me, so I use this information to consider which rules I should target for performance optimizations.

Problem: This list only shows the top 10 longest-running rules and their durations. Given that I have hundreds of rules enabled, this severely and unnecessarily limits the usefulness of this feature for me.

Your take on the correct solution to problem.

Several ideas:

1. Get rid of the limit entirely (remove .slice(0, 10)).
2. Increase the limit substantially to at least 100.
3. Make the limit configurable using the existing TIMING environment variable by changing it from a boolean to an integer (in a backwards-compatible way).
   • TIMING=1: show the first 10 (due to minimum of 10)
   • TIMING=5: show the first 10 (due to minimum of 10)
   • TIMING=10: show the first 10
   • TIMING=15: show the first 15
   • TIMING=100: show the first 100
4. Make the limit configurable using a new TIMING_LIMIT integer environment variable.

Are you willing to submit a pull request to implement this change?

Yes, all of the proposed solutions would be trivial to implement, and I could implement the preferred solution promptly.

[mdjermanovic]

I think this should go through the RFC process. It might be a small change in the code at the end, but it is related to the core and it isn’t entirely clear whether it is a non-breaking change.

@bmish feel free to create an RFC 😃

[bmish]

It sounds like my proposed solutions 3 and 4 are currently favored. I can put together an RFC once we settle on a decision.

My top preference is solution 3 which could be considered the most elegant since it doesn’t add any extra environment variables. Note that I would keep the output list to a minimum of 10 rules to avoid causing a breaking change, and because there’s not much reason to shorten the list beyond that.

If we went with 4, I would leave the existing TIMING variable alone (not deprecate it), since most people probably don’t care about setting a specific limit.