Port System.Memory performance improvements to Convert.TryFromBase64Chars

[ahsonkhan]

From dotnet/corefx#24888 (comment)

cc @jkotas, @stephentoub, @KrzysztofCwalina

[jkotas]

This should be a copy&paste port with a few small adjustments.

The Convert api allows (and ignores) whitespace characters in the input - this is likely to be the source of its slowness compared to Base64. We can't just copy&paste and replace byte with char here - the whitespace requirement changes a basic assumption of the Base64 implementation.

This issue was opened with the assumption that the api's are equivalent and the implementation can be ported over directly - as stated above, it's not that simple.

[stephentoub]

This issue was opened with the assumption that the api's are equivalent and the implementation can be ported over directly - as stated above, it's not that simple.

This issue is really about improving the performance of Convert.TryFromBase64Chars. Maybe the changes can't be ported directly. Maybe because the API is more flexible in what it accepts it won't be as optimizable. But that doesn't mean nothing can be done, does it?

We can always look at improving the performance in any api - we don't automatically track each one with an issue though. This one was seen as a "low-hanging fruit" during a PR so we opened an issue - a closer look showed it to be not so low-hanging.

However, if you believe there's a concrete opportunity here in this particular api, feel free to open an issue or reopen this one with a more accurate description - I just don't want a 2.1 milestone issue hanging around though when the premise underlying it has changed.

[stephentoub]

What prevents the logic from being ported, and just treating whitespace as "invalid data" for which we then fall back to the slower algorithm?

Ok, fair answer. I'm not sure the added complexity is worth it here but that's something that can only be answered by measuring the perf results. I'll reopen.