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

[MON KEY]

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