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

From: Andy (atompkins_at_[hidden])
Date: 2007-06-01 17:04:36

Jos Hickson <jos.hickson_at_[hidden]> wrote in
news:1180722852.7102.27.camel_at_[hidden]: 

> 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.

Whatever the solution, I will put warnings in the docs where needed.  I
do agree that creating better uuids are more important than creating
them fast. 

> 
> 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.

agreed

> 
> 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.

This may be the best solution.

I need to take some time to think about all this.  I do want a solution
that works for everyone. 

> 
> 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!

You're welcome.

< snip >

> 
> Jos
> 

Andy.