Adding the rule you’re asking for will not solve any problem unless we understand, what the actual problem is. Asking for adding a rule, is like asking for changing sunglasses to drive faster after having exchanged car and driver.
To give some explanation: the rules don’t do anything, the code is basically “if rule is active, and a condition is met for this rule, create an issue”, adding a new rule with old name would change this to “if new rule with old name is active, and a condition for this rule is met, create an issue”.
Nevertheless, there could be parts in the code - that are not related to a specific rule - that could be optimized. But I didn’t had any performance issues so far, therefore I didn’t profile the plugin or run any benchmarks, as this would require some time, which I honestly don’t have a lot to spare.
So unless you provide a detailed log of your build/analysis execution, do a proper performance analyis or provide a proper reproducer, that in someway would help to pinpoint where the actual problem is, nothing is going to happen.
Here are some ideas to spark your creativity in problem search:
- run an analysis on sonarqube 7.6 without any mutation analysis rules active, but with running the pitest analysis (the maven/gradle plugin)
- activate more or less mutation-analysis-rules
- analyse logs / debug logs, with timestamps, to see when mutation-analysis-plugin starts/finishes
- run just the pitest analysis (no sonarqube at all)
- what are the jvm settings of your build
- what is the hardware configuration of your build system
But in summary: provide some solid proof, that the performance problem is caused by the mutation-analysis-plugin.