Improve perf of Encoding.GetEncoding(int) (dotnet/coreclr#6907)
authorJustin Van Patten <jvp@justinvp.com>
Thu, 25 Aug 2016 18:54:11 +0000 (11:54 -0700)
committerJan Kotas <jkotas@microsoft.com>
Thu, 25 Aug 2016 18:54:11 +0000 (11:54 -0700)
commit42fa62e3eae4ba96f0b9ba786031c9e891ae5205
tree4778c4de081ecd25a347d1f951865e906e8f3bc4
parent39613aae6cc81adf43372d775d14a2fc45c17900
Improve perf of Encoding.GetEncoding(int) (dotnet/coreclr#6907)

`Encoding.GetEncoding(int)` caches encoding instances in a `Hashtable`.
This involves locking and boxing the codepage (potentially multiple
times). For the encodings that are already cached in static fields
(e.g. UTF8, Unicode, ASCII, etc.), this is unnecessary overhead --
these instances do not need to be stored in the `Hashtable` because
they are already stored in static fields.

It turns out the only instance that would be stored in the
`Hashtable` in CoreCLR is UTF32BE. Thus, on CoreCLR, we can remove the
use of the `Hashtable` altogether, and instead store the UTF32BE
instance in a static field. This means the `Hashtable` static field,
lock object, and box allocations go away entirely on CoreCLR.

We now check for the encodings that can be cached in static fields in a
switch statement up-front. On Desktop, it then falls back to doing the
`Hashtable`-based lookup/storage, and only boxes codepage once.

Commit migrated from https://github.com/dotnet/coreclr/commit/24918bf5e4bd94547b994a3a3f8d565e972eeac6
src/coreclr/src/mscorlib/src/System/Text/Encoding.cs
src/coreclr/src/mscorlib/src/System/Text/UTF32Encoding.cs