On Aug 31, 2013, at 3:30 , Sven Van Caekenberghe <s...@stfx.eu> wrote:
> > On 31 Aug 2013, at 13:47, Stéphane Ducasse <stephane.duca...@inria.fr> wrote: > >> Sabine >> what we could do is to propose a "subclass of UUID" and to group several >> UUID generators. >> Like that with a couple of classes, we could get a better eco system where >> people can pick the one they want. >> >> stef > > I just made my own, called NeoUUIDGenerator, > http://www.smalltalkhub.com/#!/~SvenVanCaekenberghe/Neo/packages/Neo-UUID > > @Sabine > > IMHO what I think a local counter does not, is give you uniques over > different machines, images, instances - that is why there is also the concept > of node identification. > > In my implementation I combine the millisecond clock, a small random number, > a counter and a node id. The node id is based on several elements, it should > be different when running multiple images. > > This is a hack, not something that I can prove mathematically. But it can't > be worse than pure random. I think the speed is also acceptable: > > | generator | > generator := NeoUUIDGenerator new. > [ generator next ] bench. '408,000 per second.' > > | generator | > generator := UUIDGenerator new. > [ generator generateBytes: UUID nilUUID forVersion: 4 ] bench. '13,300 per > second.' > > Sven So sorta like UUID type 3/5, but with a custom object identifier scheme, and no hashing? Not sure it'd be fair to call that any kind of UUIDGenerator anymore, as the UUID standard and its encompassing types is a pretty well-defined ;) IIRC, the reason those went out of flavor in favor of type 4, is the fact they do potentially identify the source computer from which they were created, and thus a purely random approach was considered better. (as long as it is just that, which, as this thread illustrates, is another matter) Cheers, Henry
signature.asc
Description: Message signed with OpenPGP using GPGMail
