Ans.: Don't think so, although coefficient of variation is an indication of relative distance (herein in duration) in time, the problem actually depends on what process is considered "healthy" and what that means anyway.
There are related concepts like robust models and ill-posed problems that are better defined. Consider that if one chooses starting values close to the solutions values the process usually is faster. Some regression methods, e.g., random search, usually take much longer to complete than others, e.g., Simplex. Also, asking a better regression "question" works wonders; Better questions often are faster to completion, for example, frequently reparameterization of the problem works faster, and yields better precision and accuracy. Related to this is that some models are hopelessly unscientific, as the units do not balance or the physics is contradicted, even if the math looks OK. In those cases, constructing models that make more physical sense leads to faster solutions, that is, if everything else on the list here is done properly, including the following consideration; the problem may be ill-posed, in which case, regression for ill-posed problems, e.g., Tikhonov regularization may be much more robust (and thus faster).
Last but not least are programming considerations. For example, using too few decimal places can destabilize a problem causing it to go into a very long or even infinite loop. Code often needs debugging for speed, the first version can take 24 hours to run, and the last 24 milliseconds. Solutions can be local optima, and not provide the correct answer regardless of speed. Fast but wrong can give a false impression of robustness. For example, some solutions may only exist in the complex domain, and unless the programming allows for those solutions, the problem will be solved incorrectly in a local real-valued minimum. In the latter case, unless the complex solutions make physical sense, and they frequently do not make sense, the model is probably the wrong one for the physical circumstances and should be swapped out for something better.
The moral of the story, if there is one at all, is to always check that the program actually converges to the requested precision, which is frequently 1/2 of the number of digits contained in the working precision. If it is not converged, then YOU did something wrong. Models that do not converge are not models, and if not converged, one has to change the code.