`Path.GetRandomFileName()` is 7 times slower on Linux compared to Windows

[adamsitnik]

Path.GetRandomFileName() is 7 times slower on Linux compared to Windows.

Slower	diff/base	Windows Median (ns)	Linux Median (ns)	Modality
System.IO.Tests.Perf_Path.GetRandomFileName	7.48	100.47	751.86

The contributor who wants to work on this issue should:

1. Run this simple benchmark from dotnet/performance repository and confirm the problem

git clone https://github.com/dotnet/performance.git
python3 ./performance/scripts/benchmarks_ci.py -f netcoreapp5.0 --filter System.IO.Tests.Perf_Path.GetRandomFileName

2. Build CoreCLR locally: https://github.com/dotnet/performance/blob/master/docs/profiling-workflow-corefx.md#Build
3. Create a small repro app: https://github.com/dotnet/performance/blob/master/docs/profiling-workflow-corefx.md#repro
4. Use PerfCollect to identify issue https://github.com/dotnet/performance/blob/master/docs/profiling-workflow-corefx.md#PerfCollect
5. Solve the issue

[stephentoub]

The bulk of the cost of GetRandomFileName is presumably in getting the randomness, which is also the only part of the code that's platform-specific and differs between platforms.
https://github.com/dotnet/coreclr/blob/master/src/System.Private.CoreLib/shared/Interop/Unix/System.Native/Interop.GetRandomBytes.cs
https://github.com/dotnet/coreclr/blob/master/src/System.Private.CoreLib/shared/Interop/Windows/BCrypt/Interop.BCryptGenRandom.GetRandomBytes.cs
I'm not sure how much that can realistically be improved. Maybe dotnet/corefx#37906 will help.

[am11]

An alternative to OS based random could be managed implementation of http://vigna.di.unimi.it/ftp/papers/xorshift.pdf, based on George Marsaglia's simple xor-shift pseudo random. e.g. https://github.com/bewaretech/PEA.NET/blob/40f851db/src/PEA/PEA/Util/FastRandom.cs#L149, which claims:

///  2) Faster than System.Random. Up to 8x faster, depending on which methods are called.

[AaronRobinsonMSFT]

/cc @lpereira

[lpereira]

There's some work improving it already in #1433. It should improve performance ever so slightly (as it doesn't always XOR with the result of srand() -- it only does so when it detects that the OS method didn't produce good enough numbers according to a simple heuristic).

Since that function doesn't necessarily needs cryptographically-secure numbers, I can use the current method (that requires a syscall on Linux) just to seed a RNG that's entirely in userspace. Probably something in the family of xorshift, as it requires very little state and is, for many non-cryptographic purposes, good enough. Will do a follow-up patch implementing this.

[stephentoub]

From the docs:
https://docs.microsoft.com/en-us/dotnet/api/system.io.path.getrandomfilename?view=netcore-3.1
"The GetRandomFileName method returns a cryptographically strong, random string that can be used as either a folder name or a file name."

[lpereira]

Ah. GetRandomBytes() isn't supposed to generate cryptographically secure numbers, so maybe GetRandomFileName() shouldn't be using it in the first place?

Since GetRandomBytes() is internal, maybe it could be renamed to GetEntropyForSeeding(), and a PRNG using something from System.Security.Cryptography (AesCcm as it's already implemented, or something like ChaCha20, which is used by OpenSSH-portable to implement arc4random(), or even RandomNumberGenerator) could be used instead?

For places where crypto-safe numbers aren't needed, GetEntropyForSeeding() can be used to kickstart something fast-but-not-crypto-safe.

This way, we clear up this confusion, keep in the managed code for longer, and go down to the native side of things when needed.

[stephentoub]

so maybe GetRandomFileName() shouldn't be using it in the first place?

Probably.

[jkotas]

The output of Path.GetRandomFileName has 8 bytes in it. I believe that it is misleading to say that it returns cryptographically strong string. It depends on how you are using this string. I think we should remove the cryptographically strong part from the docs.

GetRandomBytes() isn't supposed to generate cryptographically secure numbers

FWIW, here is a discussion how we ended up with this: dotnet/corefx#16652 . The output of it are cryptographically strong bytes (for some definitions of cryptographically strong) on all platforms we care about.

[JeremyKuhne]

Triage: We should be clearer in the docs around using the terms "cryptographically strong" (probably remove it). Changing the the heuristics here should be done with caution as it will potentially cause undesirable consequences. If we can be confident in the distribution of names, and we don't change the set of characters that are used, than changing this would probably be fine.

[DeerBear]

What's wrong with reading from /dev/urandom as a seed?