So there was no particular optimization?

Ok, I just tested this out. IsNumeric is significantly slower than using Double.TryParse directly, though there would be some overhead to the function call the way FourBlades has it, it may well be that the function call overhead is less than the penalty for using IsNumeric.

In further testing, I found that when MS says parse, they mean parse. If the string truly is numeric, then the length of the string is directly related to the time taken by either the IsNumeric or the Double.TryParse function. However, if the string is not numeric, then the time taken is determined by where the first non-numeric character is in the string starting from the left. Therefore, the string is being parsed from most significant to least significant, and parsing ends as soon as the first non-numeric character is encountered, or the end of the string is reached.

Lastly, both functions are faster if the result is true than if it is false.

However, upon examining the IL, the Double.TryParse line calls the function of the same name with this line:

IL_0007: call bool [mscorlib]System.Double::TryParse(string,
float64&)


However, IsNumeric doesn't quite do that. If it is calling Double.TryParse, it is buried under another layer, which would account for the slower operation of the IsNumeric call:

IL_0005: call bool [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.Versioned::IsNumeric(object)

By the way, for my testing, I called each in a loop of 40,000 iterations, and the difference was only in the vicinity of a 10-30% penalty for IsNumeric. What this means is: It really doesn't matter. Double.TryParse is faster, but the difference is so small you will never see it. The other thing this means is that I'm a geek for even having a test bed app where I can look at minutiae like this.