3 ms·
> It's not better than the method I suggested, but requires to use I/O for every generated ID. So without gaining anything you lose performances. I highly doub
by deathanatos 11y ago
> It's not better than the method I suggested, but requires to use I/O for every generated ID. So without gaining anything you lose performances.
I highly doubt unique ID generation is going to be the bottle neck in your app. Even if is, while your method is faster, it is not that much faster; for me in Python:
In [15]: %timeit hashlib.sha1(b'100'+seed).digest()
1000000 loops, best of 3: 632 ns per loop
In [17]: %timeit dev_urand.read(20)
100000 loops, best of 3: 1.08 µs per loop
In [22]: %timeit uuid.uuid4()
10000 loops, best of 3: 15.7 µs per loop
- antirez 11y agoIn certain systems (OSX, certain *BSD), /dev/urandom is an alias for /dev/random so the generator will completely block waiting for entropy.
- swhipple 11y agoOn FreeBSD it is the other way around: /dev/random will never block once seeded. /dev/urandom as a symlink will give the same behavior. I haven't tried OS X, but given that it also uses a PRNG (Yarrow) for /dev/random, I would expect it to behave similarly. Are you able to reproduce the described behavior?