Fork me on GitHub
#cljs-dev
<
2022-03-29
>
Adam Kalisz15:03:29

With the release of Clojure 1.11 there is random-uuid in CLJS and CLJ as well. I have looked into the CLJS version and the semantics there deviate from the approach in Clojure in that it is not using cryptographical quality pseudo-random generator. Also, it seemed, invoking random-int 31 times is a bit excessive. So here is a patch to make it more efficient - it leads to 2x better performance in my testing. https://clojure.atlassian.net/browse/CLJS-3369 could you @dnolen and @mfikes please have a look? The overall approach is the same and it is just a few lines. After that, I think some of the approaches shown here: https://github.com/clojure/clojurescript/pull/161 and https://clojure.atlassian.net/browse/CLJS-2386 should be considered to give well distributed/ cryptographical UUIDs where possible and perhaps falling back to the lesser/ faster solution when the API isn't available or the programmer wishes so.

dnolen15:03:15

@adam.kalisz thanks, will take a look when I have time

👍 1
😄 1
dnolen16:03:07

@adam.kalisz using secure random generator if available is also a fine idea, feel free to open a ticket and patch for that too

👍 1
Adam Kalisz09:04:53

How would you approach the check? Would you do the check on first invocation of the function saving the result for the runtime of the program using something like defonce or at the top of the namespace more or less globally? I don't want to introduce overhead in some bad place, ideally, it should also be visible, which of the implementations is in use - the crypto one or the pseudo-random one.

Adam Kalisz16:04:05

Btw. the widely support .getRandomValues isn't all that fast - probably the array manipulation has considerable overhead. The .randomUUID version is a bit faster than the current random-uuid, but still considerably slower than the pseudo-random version that I propose.

Adam Kalisz16:04:06

I think, the array version could be much faster, if we got larger random array at once and just took chunks out of it if multiple random uuids are desired. This would basically require a function with internal state - some kind of "/dev/urandom" as a lazy sequence that would on demand fetch another array if the previous one would be "depleted".

Adam Kalisz08:04:17

I had an idea how to do that. I have to check if this is thread-safe etc. but this could be it. It seems to be rather efficient too.