[boost] [uuid] uuid::create() is extremely slow

From: Jos Hickson (jos.hickson_at_[hidden])
Date: 2007-06-01 14:34:12

On Fri, 2007-06-01 at 17:13 +0000, Andy wrote:
> "Jos Hickson" <jos.hickson_at_[hidden]> wrote in
> news:fc03d05a0706010913l4865ef29re605685969592243_at_[hidden]: 
> 
> > On 01/06/07, Dave Jenkins <david_at_[hidden]> 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