On Fri, 2007-06-01 at 17:13 +0000, Andy wrote:
"Jos Hickson" <jos.hickson@gmail.com> wrote in news:fc03d05a0706010913l4865ef29re605685969592243@mail.gmail.com:
On 01/06/07, Dave Jenkins <david@jenkins.net> wrote:
Andy, You did a nice job speeding up the uuid::create(engine) function to 0.4 seconds for 1 million UUIDs. But now the uuid::create() function is extremely slow - 131 seconds for 1 million UUIDs (source code below). Can you change it to use a static mt19937 engine?
There was opposition to using static objects because of threading concerns. I do want a function that doesn't require the user to create a random number generator themselves.
If I use a static engine, I need to protect it with a mutex. This is not optimal because there is the overhead of locking and unlocking the mutex. Some people would rather have a static engine per thread using thread local storage. This still requires one to link with Boost.Thread. I created the uuid::create(Engine) function (great advice from this list) so that users could do whatever they want (static engine per thread, use thread local storage,...).
The uuid::create() function should handle the common case and not be best for all situations. So, I guess I need help to determine what the common case is.
I take it that means that the documentation for uuid::create() should have a warning saying "only useful for situation X" or something. IMHO the responsibility of a UUID library is to provide the best possible UUIDs and if this means having a static without thread protection and the warning being about the lack of thread safety then I think that is preferable. I didn't see any of the original reviews but I gather from what you said you'd improved that there was some issue about the quality of the seeding. If so, then as uuid::create() is the only thing that uses the seeding mechanism it would seem strange to put effort into improving it if the random number generator is then compromised by the repeated reseeding. Obviously, though, if the common use case is to only ever create a single UUID for the lifetime of an application then it should probably stay as it is. FTW I think this is what our most common use case will be. If things are left as they are, however, then it might be useful to give a user access to the seeding mechanism you use so that they don't need to implement their own if they are going to use the uuid::create(Engine) method. Otherwise I'd just like to say thanks for the very useful library and as we are about to start using UUIDs the timing could not have better!
On a related note: doesn't reseeding the random number generator every time uuid::create() is called reduce the quality of the random numbers from the mt19937 engine?
Probably.
Doesn't the randomness then come from the seeding mechanism which is used? So, on the whole it would indeed be better to use a static engine if possible.
Regards,
Jos
Andy.
Jos