[vivace-graph-devel] every time we UUID 128 bits die down the bit hole

[Kevin Raison]

I am convinced that this is an excellent idea;  I also noticed that you
have been working on it in your github branch of VG.  Let me know when
it is ready to merge into the mainline so that we can play around.

Also, to justify the original use of make-v1-uuid:  it was simply easy
and worked well enough.  Now that there are others interested in this
project, it is definitely time to use a better solution.

Cheers,
Kevin


On 9/7/11 1:27 AM, MON KEY wrote:
> While reviewing Franz's documentation of Agraph's UPIs:
> 
> http://www.franz.com/agraph/support/documentation/current/lisp-reference.html#function.make-upi
> 
> it occured to me that vivace-graph-v2 should consider using Unicly
> https://github.com/mon-key/unicly rather the current uuid library.
> 
> Obviously I'm biased :)
> 
> In any event, its pretty clear that Franz is using some form of UUID
> truncated from 16 to 12 bytes for maintaining triple identity.
> 
> What isn't clear is whether the top four bytes are needed for type
> addressing by the underlying Lisp or if the decision had more to do
> with a performance bottleneck with frobbing ~128bit normative UUIDs
> (e.g. as per RFC 4122).
> 
> Regardless, vivace-graph-v2 should move away from uuid:make-v1-uuid
> (its slow, ugly, and buggy) I would suggest that there may be some
> significant gains to be had by:
> 
>  a) taking advantage of Unicly's fast v3 and v5 UUID generation I'm
>     convinced that vivace-graph-v2 could benefit by caching UUID
>     namespaces for its various triple indexes and using these to
>     generate v3/v5 UUIDs instead of the current scheme of constantly
>     hashing up disposable UUIDs by banging on the system clock!
> 
>  b) utilizng Unicly's ability to convert UUIDs to/from various
>     representations it might be possible to extend Unicly's bit-vector
>     UUID representation out beyond 128 bits in order to allow triples
>     to carry type information. Tacking one more octet (#*11111111)
>     onto a Unicly UUID bit-vector would buy a lot of space to address
>     types. Likewise, taking advantage of Unicly's ability to convert
>     UUIDs to integer values would prob. aid certain Btree schemes by
>     branching on numeric greater/lessthan as opposed to lexical
>     schemes which frob string-greater/string-lessthan
> 
> _______________________________________________
> vivace-graph-devel mailing list
> vivace-graph-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/vivace-graph-devel