[Mono-dev] Removing unsafe code in BitConverter and speedups

[Avery Pennarun]

On 5/10/08, Alan McGovern <alan.mcgovern at gmail.com> wrote:
>  1) Removed all unsafe code, everything is managed now
>  2) Improved performance of DoubleToInt64Bits and Int64BitsToDouble
>  pretty significantly, about 2.5x faster. I'd say this is mostly
>  because this implementation doesn't create an intermediate array when
>  performing the conversion.
>  3) Small speed increase to the GetBytes() overloads (1-4%)
>  4) ToInt16 and ToInt32 takes a 30% and 25% speed hit respectively.
>  ToInt64 is 7% slower.

#4 is a shame.  Things like dbus-sharp do an awful lot of ToInt32 (and
back) conversions.  It happens that *my* use of dbus-sharp also uses a
lot of doubles, so #2 sounds great for me, but it seems suspiciously
like doubles are less common in network streams than ints.

Is #1 really an advantage in the core library?  Perhaps I've missed
some documentation here.  It seems like these sorts of small, fast
functions are exactly what would benefit from being written in native
code, much like key C functions are optimized in assembly.

Side question: is there a sort of BitConverter that *always* returns
big-endian or little-endian, as requested?  dbus-sharp (at least the
version I'm looking at) resorts to unsafe code to do this, which is
pretty gross.  I see System.Net.IPAddress has methods like
HostToNetworkOrder() which will guarantee big endianness, but you
can't guarantee little endianness that way.

Have fun,

Avery