richardcocks commented on issue #4066: URL: https://github.com/apache/iggy/issues/4066#issuecomment-5552773744
For rust, the RNG is already fast, so I won't be changing rust. That's a good point about Snowflake, it's only suitable in a server environment where machines can coordinate their IDs. For C#/Java/Go, my benchmarking shows a 10-15% throughput improvement, it's modest but it's also an easy change to make, and I think leaves the intent more clear, it needs a 16 byte random id and it will now generate a random 16 byte buffer. Going in and out of UUID was confusing for no benefit. Profiling and benchmarking the node client indicates there is a vast difference in cost between CSPRNG and Math.Random, eclipsing any win from just dropping string uuid handling: #### All Node mint options, measured end-to-end (BITS=42, pack=1, REPEAT=10) | mint | msg/s | vs baseline | crypto? | fork-safe? | |---|---|---|---|---| | **baseline** — old uuidv4-string | 192,136 | 1.00× | yes | yes | | `crypto.randomFillSync` | 266,796 | 1.39× | yes | **yes** | | **Math.random ×4** | **475,669** | **2.48×** | **no** | no | | — *fastbytes ceiling (ref)* | 435,888 | 2.27× | no | — | | — *seq floor (ref)* | 467,620 | 2.43× | no | — | ( The reason it beats the sequential baseline is that the sequential baseline was generating before being passed through the old u128ToBuf handler. ) Just removing the the string manipulation and UUID construction gave around a 40% increase, but switching to Math.Random gave a 148% throughput increase. These are somewhat artificial benchmarks, but the difference here is something I'm still surprised by, which is why I've torn down the lot and re-ran this entire experiment twice already! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
