Performance and Coverage both

Hi Paras,



You need separate runs to measure coverage and performance.

This is because usually these two profilers are used to measure different things.

Coverage is measured to figure out how well the code is covered by tests (note, that coverage profiler does not measure if all possible execution paths were covered, but just looks if the given line of code was executed or not). Performance is usually out of scope when measuring the coverage.

When measuring performance, some certain execution path of the given usage scenario is of interest and it does not matter if the other code was executed or not.

Paras:

even if we had these two profilers concurrently available, I don't think it would be a desirable combination. Any profiling adds *some* overhead to the execution - in case of coverage and performance, much smaller than for memory, for example. So, when you profile for performance, you don't want any additional overhead - and in fact, you probably want to specify profiling areas to have code that does not need profiling running without overhead. So, adding coverage to the mix would actually be counter productive, in my view.



A combination of coverage and memory profiling would actually make a lost more sense. Unfortunately, we currently do not support combining these two, but it is possible we will be looking at it in the near future.



Best regards,

Sergei