"profiling" a slow pitest run: how to make PIT faster

[Russ Schampers]

I was wondering if there is a way to profile a particularly slow running Pitest. I have a project we are refactoring to be better. It currently only hits 40% mutation coverage and the runs take 50 mins locally, 25 minutes on our build job (better hardware). A big reason for this may simply be the lack of code quality (and testing quality). I'm wondering if there is a scientific approach to figuring out exactly where Pitest is spending most of it's time so I can focus my efforts in the area of greatest return first.

[Gordon Daugherty]

This article doesn't address your question directly but offers other ways to reduce the time spent running PIT tests:  https://blog.frankel.ch/faster-mutation-testing/

I echo your question and would like to know how to assess where the time is spent in my PIT tests. It'd be nice to slice it by the name of each of my Test classes and also separately slice it by class of PIT permutation. That way I can identify when have a test that's more of an integration test that needs to be named properly to exclude it from running with unit tests.