Improve Uri.UnescapeDataString codepath -> UriHelper.UnescapeString

[safern]

After doing an investigation on some performance traces collected from some mvc aspnet applications scenarios we found that a considerable amount of char[] objects were allocated on the GC Heap which are coming from Uri.UnescapeDataString codepath that is calling UriHelper.UnescapeString (source code) which receives a char[] as the destination of the unescaped string and then creating a string from that char[].

I know it would be a big change but we could probably consider using the sourceString that is already allocated or using a PooledStringBuilder which uses an ArrayPool for the buffer cache as explained here:

• Port System.Net.WebUtility missing members corefx#13875 (comment)

/cc @danmosemsft @jkotas @stephentoub

[danmoseley]

Concretely in the MVC scenario captured, UnescapeDataString is 1% of CPU time and 1.5% of strings (which doesn't sound like much but there's a lot of strings in this scenario). There really doesn't seem like a great reason to make a char[] and certainly not to make a new string out of it given probably most times the result will be the same as the input.

[safern]

Currently working on this

[karelz]

Flipping back to "up for grabs"
Next steps: Pick up dotnet/corefx#16456 and finish it.
Complexity: Medium

[safern]

Just FYI: I had an implementation proposal but as we had other priorities now I stopped pursuing that but I did see improvements. Here is the PR whit my proposal: dotnet/corefx#16456

[stephentoub]

See https://github.com/dotnet/corefx/issues/22569#issuecomment-377836840 and stephentoub/corefx@c28e627, which also covers these code paths.

[jkotalik]

In Kestrel, we have a class which does path normalization, which has similar concerns to Unescaping. May give some inspiration for ways to improve the perf of UnescapeDataString: https://github.com/aspnet/AspNetCore/blob/master/src/Servers/Kestrel/Core/src/Internal/Http/PathNormalizer.cs