Perf: Small performance improvement for CalculateChecksumForPath

[vcsjones]

This is a small performance improvement for CalculateChecksumForPath:

1. MD5 hashes are stack-buffer size friendly, so switch to the buffer-writing MD5.HashData and write to the stack.
2. Replace BitConverter.ToString(..).Replace(..) with Convert.ToHexString. This eliminates a 32 character string allocation.

Note that this method could be further optimized to make it near allocation-less at the cost of readability, adding complexity. and using unsafe code. But it isn't clear to me how "hot" this code path is. Right now the allocations scale with the length of the path. However, these changes are small and don't harm the readability of the method.

Benchmarks:

Method	PathLength	Mean	Error	StdDev	Gen0	Allocated
After	260	815.4 ns	5.43 ns	5.07 ns	0.0591	376 B
Before	260	1,054.6 ns	2.77 ns	2.59 ns	0.0839	536 B

Validation
How did you test these changes?

• Built and ran the app
• Tested the changes for accessibility

Screenshots (optional)
Not really applicable.

[yaira2]

For what it's worth, I don't think we're actually using this right now but it's a good reminder for us to implement #3722

[0x5bfa]

@yaira2 To use stackalloc will be helpful if they are going to calculate considerably long binary data like file content. In this case, they calculate path.

[hishitetsu]

LGTM, but actually, this code does not appear to be used at all.

it's a good reminder for us to implement #3722

Yes. In fact, thanks to @vcsjones, we were able to implement #3722! I appreciate it very much.
dotnet/runtime#63757

[yaira2]

@vcsjones thank you!