His Math.seedrandom() is very slow, however, if you let it gather entropy by walking the window object: about 700ms on Firefox, 100ms on other browsers that I tried. Much better to call his seedrandom with some server-generated random string like, perhaps, a real UUID or two

BTW, it seems like Math.random() is the biggest performance bottleneck. Do you have any feel for how David Bau’s implementation compares to the native one?

Also, is there really a need for a better RNG? I would expect the native implementations to be pretty good already. But I don’t have any concrete data for that assumption.

David Bau provides a much better, seedable random number generator at http://davidbau.com/archives/2010/01/30/random_seeds_coded_hints_and_quintillions.html

I wrote up a slightly different approach to generating UUIDs at http://blogs.cozi.com/tech/2010/04/generating-uuids-in-javascript.html

That’s a really good question. The only verbiage I see in rfc4122 about this is in section 4.4, where it says, “Set all the other bits to randomly (or pseudo-randomly) chosen values.” But I don’t read this as saying each bit must be generated by a unique call to a random number function. Random # generators are “in the business” of creating numbers where each bit is randomly set. So the hex values I’m using are simply clusters of 4 random bits produced by the Math.random() function.

In fact, there’s a good argument that *fewer* calls to Math.random() is better. Pseudo-random # generators are typically evaluated based on how many #’s they can produce before repeating. So by minimizing the # of calls, we’re maximizing the number of UUIDs we create before the generator begins repeating itself.