Thanks for the contribution, however I'm going to pass on this PR at this time. The perf improvement doesn't justify the increased bundle size, or the maintenance burden of having multiple, separate implementations for stringify().

What about just going for the bytesToHex?

I'm afraid the value just isn't there for this.

We're at a point with this module where performance is simply not a high priority. The vast majority of use cases for UUIDs involve operations that are several orders of magnitude slower than UUID generation. E.g. v1() perf is on the order of 1,000,000 ops / second. For v4() it's ~10,000,000 ops / second. Contrast that to databases or memory caches or network requests, where things typically max out at 1,000-10,000 ops / second. UUID perf ends up "in the noise".

If you have a real-world use case where the performance difference here actually matters (e.g. "This will reduce our AWS costs by $XXX/month"), I'd be very interested in hearing about it. But barring that, there's not really any benefit here to offset the increased code size and complexity (trivial as that may seem.)

(Edit to add: FWIW, we have taken PRs in the past on the basis of perf improvement - specifically #513 and #597 - but those yielded > 4X increases to perf for v4(), which is the main API people use. And, too, the code changes were relatively small.)