crypto: improve randomUUID performance

[rangoo94]

I very like the idea of including UUIDv4 into node.js core. I think that maximizing its performance could lead to further standardization. The initial version still had the potential for improvements, so I took some effort into it.

Benchmark results

After each step (separate commit), I ran crypto/randomUUID.js benchmark to observe the performance difference.

• Cache - entropy cache
• Pre-allocated - memory reserved on crypto module initialization
• Post-allocated - memory reserved after first crypto.randomUUID() call

Step	Description	With cache	%	Without cache	%	Pre-allocated	Post-allocated
0	Current implementation	3,630,047	100%	444,904	100%	144B (kHexDigits)	2048B (cache)
1	Decompose operations to separate functions	3,755,310	103%	448,765	100%	144B (kHexDigits)	2048B (cache)
2	Eliminate intermediate buffer (slice on entropy cache)	4,826,939	132%	442,647	99%	144B (kHexDigits)	2048B (cache)
3	Optimize disableEntropyCache access	5,327,442	146%	445,531	100%	144B (kHexDigits)	2048B (cache)
4	Serialize UUID per byte (cache 00-ff strings)	18,173,445	500%	474,999	106%	2064B (kHexBytes)	2048B (cache)
5	Allocate kHexBytes on first randomUUID() call	16,416,650	452%	466,446	104%	0B	2048B (cache) + 2064B (kHexBytes)

Entropy cache size

Entropy cache size contributes to the performance, so I prepared a matrix of different sizes on different variants for comparison.

Step	1024B	%	2048B (current)	%	3072B	%	4096B	%	5120B	%
3	4,896,245	134%	5,327,442	146%	5,502,509	151%	5,557,077	153%	5,623,439	154%
4	13,795,762	380%	18,173,445	500%	19,831,019	546%	20,960,149	577%	21,807,676	600%
5	12,673,362	349%	16,416,650	452%	17,768,837	489%	18,796,783	517%	19,255,872	530%

Increasing the entropy cache could be considered for variants 4 and 5, as it will improve ~10% per 1KB of additional cache.

Summary

There are 3 approaches to include the improvements, depending on what is expected:

• Minimal resources - variant 3 - it simplifies the current algorithm without any downsides and ~50% improvement
• Maximized performance - variant 4 - it's far faster, but using crypto, even without randomUUID, will take ~2KB of memory
• Good performance, opt-in - variant 5 -similar to 4 (slightly slower), but these additional ~2KB will be allocated only after script will use randomUUID

What are your thoughts about that?

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines