[GODRIVER-2361] Investigate using "x/exp/rand" or "google/uuid" packages to improve UUID generation Created: 30/Mar/22 Updated: 28/Oct/23 Resolved: 23/May/22 |
|
| Status: | Closed |
| Project: | Go Driver |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.10.0, 1.10.0-beta1 |
| Type: | Improvement | Priority: | Unknown |
| Reporter: | Matt Dale | Assignee: | Qingyang Hu |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | neweng, techdebt | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Description |
|
While investigating Additionally, the google/uuid package supports pooling random values for generating random UUIDv4 values, which may mitigate the performance impact of using "crypto/rand". We should consider using that dependency to replace the "uuid" package. tldr; We should investigate if using the golang.org/x/exp/rand or github.com/google/uuid packages would make a meaningful improvement, either in simplicity of code or performance. If so, we should update the session ID UUID generator to use the best package. Definition of done:
|
| Comments |
| Comment by Githook User [ 23/May/22 ] |
|
Author: {'name': 'Qingyang Hu', 'email': '103950869+qingyang-hu@users.noreply.github.com', 'username': 'qingyang-hu'}Message: |
| Comment by David Golden [ 09/May/22 ] |
|
I see that mt19937 is unfortunately GPL3, but perhaps there are other MT libraries with more permissive licenses. E.g. here's one: https://github.com/goark/mt with an MIT license. As I suggested earlier, I think a mix of a static, per-process crypto portion plus per-UUID random bits from a (crypto-seeded) MT PRNG for the remaining bits is going to give the best safety/performance tradeoff. |
| Comment by David Golden [ 31/Mar/22 ] |
|
For non-crypto PRNG, I suggest also benchmarking a Mersenne Twister PRNG like https://pkg.go.dev/github.com/seehuhn/mt19937 I'd also add that I'd strongly prefer strong uniqueness over performance unless there is some compelling reason why UUID generation is a hotspot in the code. In that regard, I'd look to develop a real-world benchmark that exercises UUID generation (inserting into lots of explicit sessions?) and see how much difference the UUID generator makes in that context. As one final thought, you could consider applying the UUID RFC recommendation in section 4.5 and generate 47-bits from a CSPRNG once per process and use it for all UUIDs (with the rest of the bits filled in with a PRNG as you do today). This might balance uniqueness with generation speed. |