hyperuuid-wasm 0.6.1 → 0.7.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 891b6e2ed78c68a12067a1dd6e8f4ba3a7328f6ba3f5ec3853e56d7c37275baa
-  data.tar.gz: 4252c3cee5c2654d852c3b3818b7de53cb9908ede2f30e6a530ebdaebf40cdd0
+  metadata.gz: a4acc2b5b222f7604e7b21efe1c5f958e7279a470f546bed3ad00089f033f13f
+  data.tar.gz: 0c9349c620020edf44cf37afbfff39480d49497ade4e63c94e9549e028ce2abb
 SHA512:
-  metadata.gz: 6fda24dba0eefff039f615a7b80ba66f1948cfc4579bc96be3d81d33f015a30ea821b18ce29cf5f6c9f76f5b72b3f4e7ffa01f3f111ea9b4bd5c7f148d805055
-  data.tar.gz: 011a274e14ea76f4ca6701ca0341c81dd2873b5b658929be8f2834832486dbf7e44312cb2f2ec6ae46da7b952d9e96e50e5c4d2785ef90c1dd32ba38e8bb9127
+  metadata.gz: c9f72f6b99806013e5c6557189c15f542ab1a4328528b07a2992770c01d4008111e1591b36cc00f567cdd6a919d89e6e81e7fd4bad8886bcfdcef10f7b1328c9
+  data.tar.gz: 6d6d7e0f7eecd6d4e62d6af9803090be5b76f90f3ee1d59534d409c92f5ee95b14d4c829af820485d3668108fbe2b500f0dc7385865de00f3a1315e225e22417

data/README.md

@@ -123,7 +123,7 @@ bytes = HyperUuid.new_v7_batch_bytes(1000)
 first = bytes[0, 16]        # ready for a BINARY(16) bind parameter
 ```
 
-**About 20x faster than `new_v7_batch`** for a 1000-UUID batch (10.4 µs versus 210 µs). The native call is identical — the difference is that `new_v7_batch` then allocates a `Uuid` object and its byte Strings for every item on top of it. This hands back the bytes the native core already produced, untouched.
+**About 40x faster than `new_v7_batch`** for a 1000-UUID batch (4.9 µs versus 202 µs). The native call is identical — the difference is that `new_v7_batch` then allocates a `Uuid` object and its byte Strings for every item on top of it. This hands back the bytes the native core already produced, untouched.
 
 The catch, and it inverts the advice: **if you need `Uuid` objects, keep using `new_v7_batch`.** Slicing these bytes into objects yourself just relocates the identical allocations into your own code, and measures no better — sometimes worse. Reach for the byte form only when bytes are the destination: a bind parameter, a wire format, a bulk load.
 
@@ -139,30 +139,30 @@ Real numbers, `benchmark-ips` on Ruby 4.0.7, linux-x64 on an Intel Core i9-11900
 
 | Call | i/s | vs `SecureRandom.uuid` |
 |---|---:|---:|
-| `SecureRandom.uuid` | 872,365 | baseline |
-| `HyperUuid.new_v4` | 4,278,000 | **4.9x faster** |
-| `HyperUuid.new_v7` (explicit ms) | 3,517,000 | **4.0x faster** |
-| `HyperUuid.new_v6` (explicit ms) | 3,487,000 | **4.0x faster** |
-| `HyperUuid.new_v6` (current time) | 3,324,000 | **3.8x faster** |
-| `HyperUuid.new_v7` (current time) | 3,320,000 | **3.8x faster** |
-| `HyperUuid.new_v5` | 1,838,000 | 2.1x faster |
+| `SecureRandom.uuid` | 943,917 | baseline |
+| `HyperUuid.new_v4` | 5,236,000 | **5.5x faster** |
+| `HyperUuid.new_v6` (explicit ms) | 3,811,000 | **4.0x faster** |
+| `HyperUuid.new_v7` (explicit ms) | 3,785,000 | **4.0x faster** |
+| `HyperUuid.new_v6` (current time) | 3,677,000 | **3.9x faster** |
+| `HyperUuid.new_v7` (current time) | 3,574,000 | **3.8x faster** |
+| `HyperUuid.new_v5` | 1,942,000 | 2.1x faster |
 
-A `HyperUuid.new_v4` — real entropy, correct version/variant bits, minted by the shared Rust core — costs a fifth of what `SecureRandom.uuid` does, because the Magnus extension is an ordinary native method call with nothing marshalled around it.
+A `HyperUuid.new_v4` — real entropy, correct version/variant bits, minted by the shared Rust core — costs less than a fifth of what `SecureRandom.uuid` does, because the Magnus extension is an ordinary native method call with nothing marshalled around it.
 
 The "current time" rows deserve a footnote, because they will not look like this everywhere. Here they land beside the explicit-ms rows: the only difference between the two is one `Process.clock_gettime(CLOCK_REALTIME)` wall-clock read, and on this machine that read is too cheap to see. On a machine with a slow clock it is the whole story — where a virtualized clock defeats the vDSO fast path the same read costs ~1µs, which puts both current-time rows at parity with `SecureRandom.uuid` while the explicit-ms rows stay well ahead of it. `SecureRandom.uuid` never reads a clock — random v4 is the only thing it does. If your clock is slow and you are minting many, read it once and pass the timestamp, or use the batch doors.
 
-The Fiddle fallback (`HYPERUUID_PURE=1`, and any platform without a prebuilt extension) keeps its own diet — a reused thread-local scratch buffer instead of two GC-finalizer-registering mallocs per call, zero-copy `String` passes for read-only inputs, an unsynchronized fast path past the load mutex — landing at 1.25x slower than `SecureRandom.uuid` for v4 (1.26 µs against 1.01 µs in its own run) and 1.45x slower for v6/v7, with the same structural story as before: `Fiddle`'s interpreted marshalling is the floor, and the batch doors are how you amortize it.
+The Fiddle fallback (`HYPERUUID_PURE=1`, and any platform without a prebuilt extension) keeps its own diet — a reused thread-local scratch buffer instead of two GC-finalizer-registering mallocs per call, zero-copy `String` passes for read-only inputs, an unsynchronized fast path past the load mutex — landing at 1.16x slower than `SecureRandom.uuid` for v4 (1.24 µs against 1.07 µs in its own run) and about 1.3x slower for v6/v7, with the same structural story as before: `Fiddle`'s interpreted marshalling is the floor, and the batch doors are how you amortize it.
 
 Batch generation still amortizes per-call cost on both backends — one native call for the whole batch:
 
 | Call | i/s (Magnus backend) |
 |---|---:|
-| `new_v6` × 1000 (individual) | 3,498 |
-| `new_v6_batch(1000)` | 4,633 (**1.3x**) |
-| `new_v7` × 1000 (individual) | 3,539 |
-| `new_v7_batch(1000)` | 4,677 (**1.3x**) |
+| `new_v6` × 1000 (individual) | 3,761 |
+| `new_v6_batch(1000)` | 4,857 (**1.3x**) |
+| `new_v7` × 1000 (individual) | 3,742 |
+| `new_v7_batch(1000)` | 4,850 (**1.3x**) |
 
-The multiplier is small on this backend for the best reason available: the individual calls are cheap, so there is little waste left to amortize, and what `new_v7_batch` spends its 214 µs on is building a thousand `Uuid` objects — the byte form above does the same native work in 10 µs. On the Fiddle backend, where each call costs 1.4 µs, the same batch is 6.7x the loop. If you need v5/v6/v7, need many at once, or need this Ruby service's IDs to agree byte-for-byte with a Go or Python service's, that's what this gem is for — and now it's the fast option too, not just the capable one.
+The multiplier is small on this backend for the best reason available: the individual calls are cheap, so there is little waste left to amortize, and what `new_v7_batch` spends its 206 µs on is building a thousand `Uuid` objects — the byte form above does the same native work in 5 µs. On the Fiddle backend, where each call costs 1.4 µs, the same batch is 6.7x the loop. If you need v5/v6/v7, need many at once, or need this Ruby service's IDs to agree byte-for-byte with a Go or Python service's, that's what this gem is for — and now it's the fast option too, not just the capable one.
 
 ## Backends
 

data/lib/hyperuuid/runtime.rb

@@ -38,6 +38,7 @@ module HyperUuid
         out = scratch
         rc = functions[:new_v4].call(out)
         raise random_source_failure("uuid_new_v4") unless rc.zero?
+
         out[0, 16]
       end
 
@@ -49,6 +50,7 @@ module HyperUuid
         # contract.
         rc = functions[:new_v5].call(namespace_bytes, name_bytes, name_bytes.bytesize, out)
         raise random_source_failure("uuid_new_v5") unless rc.zero?
+
         out[0, 16]
       end
 
@@ -68,6 +70,7 @@ module HyperUuid
 
       def new_v6_batch(count, unix_millis)
         return "" if count.zero?
+
         out = buffer(count * 16)
         rc = functions[:new_v6_batch].call(unix_millis, count, out)
         case rc
@@ -93,6 +96,7 @@ module HyperUuid
 
       def new_v7_batch(count, unix_millis)
         return "" if count.zero?
+
         out = buffer(count * 16)
         rc = functions[:new_v7_batch].call(unix_millis, count, out)
         case rc

data/lib/hyperuuid/uuid.rb

@@ -82,7 +82,9 @@ module HyperUuid
         when 6 then Runtime.v6_unix_millis(bytes)
         when 7 then Runtime.v7_unix_millis(bytes)
         else
-          raise ArgumentError, "timestamp is only defined for version 6 or 7 UUIDs, got version #{version}" if raise_on_mismatch
+          raise ArgumentError,
+                "timestamp is only defined for version 6 or 7 UUIDs, got version #{version}" if raise_on_mismatch
+
           return nil
         end
       Time.at(millis / 1000, millis % 1000, :millisecond).utc
@@ -168,6 +170,7 @@ module HyperUuid
     # Byte-order comparison against +other+, or +nil+ if +other+ isn't a Uuid.
     def <=>(other)
       return nil unless other.is_a?(Uuid)
+
       bytes <=> other.bytes
     end
 

data/lib/hyperuuid.rb

@@ -18,7 +18,7 @@ require_relative "hyperuuid/runtime"
 module HyperUuid
   # This gem's own version — distinct from the RFC 9562 UUID *versions* (v4/v5/v6/v7) the
   # rest of this module generates.
-  VERSION = "0.6.1"
+  VERSION = "0.7.0"
 
   # The widest batch count, and the longest v5 name in bytes, the native ABI carries (a u32).
   # (The millisecond count is a u64; unix_millis_from refuses anything wider.)

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: hyperuuid-wasm
 version: !ruby/object:Gem::Version
-  version: 0.6.1
+  version: 0.7.0
 platform: ruby
 authors:
 - Brian Buvinghausen