Add nope-id to benchmark

[ai]

cc @orhanayd

[orhanayd]

Thank you soo much!
nope-id latest version is 1.1.0. just for inform. Thank you. @ai

[ai]

I have 1 day cold-down (to reduce supply chain attack risks). I temporary disable the cold-down for nope-id 17fb99a

The current results are from CI:

crypto.randomUUID       14,859,099 ops/sec
uuid v4                  9,456,355 ops/sec
@napi-rs/uuid            7,000,646 ops/sec
uid/secure               7,318,120 ops/sec
@lukeed/uuid             6,241,275 ops/sec
nope-id                  5,567,338 ops/sec
nanoid                   5,412,358 ops/sec
customAlphabet           6,565,742 ops/sec
nanoid for browser         485,023 ops/sec
secure-random-string       414,150 ops/sec
uid-safe.sync              413,603 ops/sec

Non-secure:
uid                     29,182,907 ops/sec
nanoid/non-secure        2,702,277 ops/sec
rndm                     2,734,241 ops/sec

Is it correct? It is more about 10% (please review the benchmark, maybe I am doing something wrong).

When you will add more tools to the benchmark in nope-id docs I will be ready to merge it.

[orhanayd]

@ai Thank you, this is really kind, and thank you for actually wiring nope-id into the benchmark.

Short version: your benchmark is correct, you are not doing anything wrong. The numbers are lower on your CI purely because of the hardware. I ran your exact harness (tinybench, Node 26) on my MacBook M2 and put it next to your CI run:

tool	M2 (tinybench)	your CI	M2 / CI
crypto.randomUUID	~23M	~14.9M	1.6x
uid/secure	~15M	~7.3M	2.1x
nope-id	~9.2M	~5.6M	1.7x
nanoid	~7.8M	~5.4M	1.4x

Same code, same benchmark, same Node, so the only variable is the CPU: a dedicated Apple M2 (ARM) versus a shared, virtualized 2-vCPU Linux runner. Everything is ~1.4 to 2x faster on my machine, which is why nope-id reads ~9M locally and ~5.6M on your CI. Absolute ops/sec is only meaningful within the same run.

In both runs nope-id was the faster of the two: ~19% ahead on my M2 (9.2M vs 7.8M) and ~3% ahead on your CI (5.57M vs 5.41M). It is never the slower one here; the margin just grows on a faster CPU, where nope-id's per-character work pays off more, and compresses under CI noise. So for URL-safe IDs nope-id keeps nanoid-class speed on modest hardware and pulls clearly ahead on capable hardware, while nanoid stays an excellent, well-designed library.

To be precise about where that speed is: among JavaScript libraries that emit a CSPRNG-backed, URL-safe id over a full 64-character alphabet (the nanoid niche), nope-id is the fastest, and it also generates UUIDv7 and ULID far faster than the dedicated uuid and ulid packages (roughly 6x and 50x, because it pools the CSPRNG into one fill per ~16 ids and maps bytes with a bitmask and an array lookup instead of fetching randomness per character). That same per-character work is why the edge over nanoid widens on a faster CPU. The only tools ahead of it for plain ids are native C++ (crypto.randomUUID) or smaller-alphabet generators: uid/secure is 16-char hex, so a 21-char uid is ~84 bits against nope-id's ~126 over the same length, faster by doing less per character, not by generating the same id faster. So the aim is to be the fastest while preserving maximum randomness per character, plus the extra formats (Snowflake, ObjectId, Sqids, typed IDs).
Please check: https://github.com/orhanayd/nope-id/tree/dev#speed-vs-entropy-where-each-library-lands

On your request: I have expanded nope-id's own benchmark to compare against more tools, now including uid, @lukeed/uuid, uuid, native crypto.randomUUID, ulid, cuid2, rndm and secure-random-string, with honest notes on each (including where they beat nope-id). It is still on a development branch and will ship in the next release. Whenever you feel the comparison is broad enough to merge nope-id into Nano ID's benchmark, I would be glad, and happy to add any other tools you would suggest.

Thanks again.

[ai]

Done! =^_^=