I own the numeric types in the Base Class Libraries, and I should comment
on this.

Functionality-wise, the original request was for the abilty to parse
without using Try/Catch. V1.0 had a TryParse method only for the Double
class. In Whidbey, all the numeric types have this functionality.

This code is indeed well optimized and it is not surprising to me that it
performs significantly faster than the current .NET Framework
implementation. However, it should be born in mind that it is not
functionally equivalent. It only works with the integer numeric types, and
it does not support all the globalization options of
System.Globalization.NumberFormatInfo, so it will not work for all cultures.

This explains only some of the performance difference, of course. The bulk
of it is for the following reasons:
1. We have never tried to optimize number parsing in general. This is just
a matter of time and reasources and sometimes space and maintenance
trade-offs. So far we have done some minor tweaks to number parsing in
Whidbey so that it will be about 20% faster, but we have not been
optimizing it specifically yet.
2. The parsing code is actually mostly shared accross all the numeric data
types. This means that parsing an In32 uses a lot of the same logic for
parsing as Double. This is good for reliability, maintenance and code size,
but there are a lot of optimizations you miss out on. We may create a
special-case parser for integer types at some point.

Feedback on whether number parsing is really showing up as a bottleneck in
real-world applications is always welcome, of course, as it helps us make
these sorts of decisions.

--------------------

<ufH98qcKEHA.4032@TK2MSFTNGP10.phx.gbl>

cpmsftngxa10.phx.gbl!TK2MSFTNGXA06.phx.gbl!TK2MSFTNGXA05.phx.gbl!TK2MSFTNGP0
8.phx.gbl!TK2MSFTNGP11.phx.gbl