@rocicorp/zero 1.12.0-canary.11 → 1.12.0-canary.13

package/out/shared/src/natural-runs.d.ts

@@ -0,0 +1,191 @@
+/**
+ * A stable sort for input that already arrives in a handful of ordered runs,
+ * for the engines whose built-in sort cannot exploit that.
+ *
+ * `Array.prototype.sort` is TimSort on V8, so already-sorted input costs N-1
+ * comparisons. **On Hermes it is not adaptive**, and the difference is not
+ * small. Sorting 100,000 objects through a two-column comparator:
+ *
+ * ```text
+ *                Hermes 0.12                V8
+ *   sorted     93.6ms / 1,483,630      0.8ms / 99,999
+ *   reversed  168.6ms / 2,571,203      0.8ms / 99,999
+ *   shuffled  134.8ms / 1,770,233     17.0ms / 1,529,373
+ * ```
+ *
+ * Hermes does fifteen times the necessary comparisons on sorted input, and
+ * reversed input is its *worst* case -- slower than random data, where an O(N)
+ * reverse would do. That matters because ordered input is the common case here
+ * and not a lucky one: rows come out of a source in primary-key order, and
+ * secondary sort keys are usually timestamps or sequence numbers that move with
+ * insertion order, so a secondary index is often built over rows that are
+ * already sorted, exactly reversed, or a few ordered batches concatenated.
+ *
+ * This merges the natural runs instead, which is O(N) on one run and
+ * O(N log R) on R of them. Measured against the same inputs:
+ *
+ * ```text
+ *                Hermes native -> runs       V8 native -> runs
+ *   sorted         93.2ms -> 5.4ms (17x)     1.0ms -> 0.4ms
+ *   reversed      166.6ms -> 6.6ms (25x)     1.0ms -> 0.4ms
+ *   20 runs       147.2ms -> 9.4ms (16x)     1.0ms -> 0.8ms
+ * ```
+ *
+ * ## Why it gives up rather than always merging
+ *
+ * A full TimSort would handle near-sorted input too, but without galloping it
+ * loses badly to V8's native sort there (8.0ms against 2.8ms on 100,000
+ * near-sorted rows, 1.26M comparisons against 268k), and galloping is a large
+ * amount of code to carry. So this returns `undefined` once the input has more
+ * runs than merging can pay for, and the caller falls back to whatever it would
+ * have done -- which keeps V8's galloping and costs Hermes nothing it was not
+ * already paying.
+ *
+ * ## Where the bound sits, and why it scales
+ *
+ * Merging R runs costs about `n * log2(R)` comparisons; a non-adaptive sort
+ * costs about `n * log2(n)` whatever the input looks like. So merging is worth
+ * it exactly while `log2(R)` is the smaller of the two, and `R <= sqrt(n)` is
+ * the region where it is at most half -- a bound that needs no fitted constant
+ * and tightens on its own as `n` grows. That is what `maxRuns` defaults to,
+ * floored at 32 so nothing below 1,024 elements changes.
+ *
+ * Read the other way round, that bound is a statement about the *input* rather
+ * than a tolerance for a number of runs: `R <= sqrt(n)` is the same as saying
+ * the average run is at least `sqrt(n)` long. Which is the useful form, because
+ * what makes merging pay is runs long enough to amortise a merge pass over, and
+ * that does not change when a data set grows. A fixed run count does: the
+ * bound was 32 until a table with 50 of something turned up, which is the
+ * failure mode this shape avoids.
+ *
+ * The floor used to be the whole bound, and a fixed 32 was too low to catch the
+ * shape this was written for. A secondary index built over a junction table
+ * whose primary key leads with the *other* column arrives as one ordered run
+ * per distinct value of that column: 50 runs of 1,200 rows over 60,000, for a
+ * table with 50 of them. Merging that is O(n log 50), but at `maxRuns` 32 it
+ * declined and Hermes fell through to the full non-adaptive sort this function
+ * exists to avoid.
+ *
+ * The bound is deliberately well inside the crossover, and comparisons are not
+ * the only cost: merging R runs is `ceil(log2(R))` passes, each writing every
+ * element, which an in-place sort does not do. So it was measured past the
+ * bound rather than up to it. Sorting 60,000 rows through a three-column
+ * comparator on an Android emulator, in a release build, medians of 3 repeats.
+ * The engine is Static Hermes 250829098.0.14 -- read out of the APK's
+ * `libhermesvm.so` rather than taken from the build config, because what React
+ * Native ships is not the engine `sdks/.hermesversion` pins. Hence
+ * `libhermesvm.so` and not `libhermes.so`: a different engine, not a later
+ * build of the one in the 0.12 table above.
+ *
+ * Which does not make that table stale, and it is worth being exact about what
+ * carries over. Its *comparison counts* reproduce on the shipped engine to the
+ * digit -- 1,483,630 sorted and 2,571,203 reversed at 100,000, and 741 at
+ * n = 128 -- so the two engines sort by the same algorithm, and the premise all
+ * of this rests on holds where it matters: `nativeSortIsAdaptive()` is false on
+ * the VM that actually runs, not merely on an old CLI. Its *times* do not carry
+ * over, in either direction: those were a standalone CLI on a development host,
+ * these are an emulator, and the shipped VM is about 2.3x faster than that CLI
+ * on the same host. Compare the counts, never the milliseconds.
+ *
+ * ```text
+ *   runs        native     merge
+ *   2          517.9ms    23.0ms
+ *   50         218.3ms    82.0ms
+ *   100        221.6ms    90.3ms
+ *   244        202.8ms   101.4ms   <- the bound at this size
+ *   400        210.7ms   110.9ms
+ *   1,000      199.4ms   121.5ms
+ *   shuffled   221.0ms   207.3ms
+ * ```
+ *
+ * The extra passes do show up -- merging costs five times more at 1,000 runs
+ * than at 2 -- but on this engine it still wins everywhere measured, and only
+ * on shuffled input does the margin close to nothing. At the bound it is 2x,
+ * which is the margin the bound is chosen to keep rather than the point where
+ * merging stops paying; a higher one would capture more, and no workload here
+ * calls for it. Note also that two ordered runs are the native sort's *worst*
+ * case (517.9ms, worse than shuffled), which is the asymmetry this whole
+ * function exists to exploit.
+ *
+ * On V8, which never reaches this path, merging holds level to about 1,000 runs
+ * (23.1ms against 24.1ms) and loses past 5,000 and on shuffled input (78.6ms
+ * against 43.0ms). That bounds how far merging scales on an adaptive engine; it
+ * does not justify the bound, since no caller gets here on one.
+ *
+ * Declining is not free, and what bounds it is runs, not comparisons: counting
+ * stops once a `maxRuns + 1`th run is known to exist, before walking that one,
+ * but every run before it is walked to its end. Measured over 100,000 elements
+ * with `maxRuns` at 32, against the comparisons the native sort then does:
+ *
+ * ```text
+ *   shuffled                     76 comparisons   0.005%
+ *   32 long runs, then more  80,000 comparisons      15%
+ * ```
+ *
+ * Raising the bound raises what a decline can cost, and the shape that pays is
+ * an input whose run count lands just past it. Over 60,000 elements in equal
+ * ordered runs, comparisons spent before declining:
+ *
+ * ```text
+ *   runs    at bound 32    at bound 244
+ *   245          7,840          59,780
+ *   400          4,800          36,600
+ *   1,000        1,920          14,640
+ * ```
+ *
+ * So a 245-run input now scans essentially the whole array where it used to
+ * stop after an eighth of it. What does *not* change is the ceiling: the worst
+ * case is `maxRuns` long runs followed by anything at all, and that walks
+ * almost every element at either bound -- 60,000 comparisons at 32 against
+ * 59,780 at 244. The old bound never bounded the scan below `n`; it only made
+ * fewer shapes reach it. Against the non-adaptive sort a decline falls into,
+ * which costs about 14.8 comparisons per element on the engine that gets here,
+ * a full scan is around 7% on top. (Measured as a fraction of V8's adaptive
+ * sort it looks like 17-19%, but nothing reaches this path on V8.)
+ *
+ * A scan budget cannot be separated from the merge budget without giving up
+ * merges that would have won: `R` is only known to exceed the budget once
+ * budget-many runs have been seen, and merging `R` runs has to scan all `n`
+ * elements regardless. Any limit tight enough to cut a decline short of `n`
+ * also rejects inputs just inside the bound, which is the case this change
+ * exists to serve.
+ *
+ * One interaction is worth naming because this bound makes it bigger. The
+ * caller in `MemorySource` tries this before its specialised numeric-column
+ * pass, so an ordering that the numeric pass could have handled may now pay a
+ * scan of up to `n` before taking it anyway. Bounded, and not a shape seen in
+ * the ten index builds of a cold pass -- the nine that merge are under 32 runs
+ * and the one that declines is string-keyed -- but the chain order is worth
+ * revisiting on its own measurement rather than inside a bound change.
+ *
+ * Of the two rows in the first table, shuffled is the shape that declines in
+ * practice, and it gives up almost at once because its runs are two or three
+ * elements long. The other is the honest worst case, where the scan walks most
+ * of the array before handing it back. Nothing in the
+ * workloads this was built for looks like that, but it is what the bound
+ * permits, and a caller sorting adversarial input should know it.
+ *
+ * ## Stability
+ *
+ * Stable, and that is load-bearing rather than incidental: callers rely on
+ * equal elements keeping their input order. Two rules preserve it. Descending
+ * runs are detected **strictly**, so equal neighbours are never part of a run
+ * that gets reversed; and the merge takes from the earlier run when its head
+ * compares equal. The counting pass also does not mutate, so an array handed
+ * back on the `undefined` path is untouched -- reversing runs first and then
+ * falling back would hand the caller's sort an array whose equal elements had
+ * already been reordered, which is how a stable sort quietly stops being one.
+ */
+export declare function nativeSortIsAdaptive(): boolean;
+/**
+ * Sorts `array` in place by merging its natural runs, and returns it.
+ *
+ * Returns `undefined`, leaving `array` **unmodified**, when it holds more than
+ * `maxRuns` runs -- the caller should then sort it however it otherwise would.
+ * `maxRuns` defaults to `sqrt(array.length)`, floored at 32; see "Where the
+ * bound sits" above.
+ *
+ * `compare` must be a consistent comparator; results are stable.
+ */
+export declare function sortByNaturalRuns<T>(array: T[], compare: (a: T, b: T) => number, maxRuns?: number): T[] | undefined;
+//# sourceMappingURL=natural-runs.d.ts.map

package/out/shared/src/natural-runs.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"natural-runs.d.ts","sourceRoot":"","sources":["../../../../shared/src/natural-runs.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiLG;AAgDH,wBAAgB,oBAAoB,IAAI,OAAO,CAc9C;AAWD;;;;;;;;;GASG;AACH,wBAAgB,iBAAiB,CAAC,CAAC,EACjC,KAAK,EAAE,CAAC,EAAE,EACV,OAAO,EAAE,CAAC,CAAC,EAAE,CAAC,EAAE,CAAC,EAAE,CAAC,KAAK,MAAM,EAC/B,OAAO,SAA2B,GACjC,CAAC,EAAE,GAAG,SAAS,CAoJjB"}

package/out/shared/src/natural-runs.js

@@ -0,0 +1,337 @@
+//#region ../shared/src/natural-runs.ts
+/**
+* A stable sort for input that already arrives in a handful of ordered runs,
+* for the engines whose built-in sort cannot exploit that.
+*
+* `Array.prototype.sort` is TimSort on V8, so already-sorted input costs N-1
+* comparisons. **On Hermes it is not adaptive**, and the difference is not
+* small. Sorting 100,000 objects through a two-column comparator:
+*
+* ```text
+*                Hermes 0.12                V8
+*   sorted     93.6ms / 1,483,630      0.8ms / 99,999
+*   reversed  168.6ms / 2,571,203      0.8ms / 99,999
+*   shuffled  134.8ms / 1,770,233     17.0ms / 1,529,373
+* ```
+*
+* Hermes does fifteen times the necessary comparisons on sorted input, and
+* reversed input is its *worst* case -- slower than random data, where an O(N)
+* reverse would do. That matters because ordered input is the common case here
+* and not a lucky one: rows come out of a source in primary-key order, and
+* secondary sort keys are usually timestamps or sequence numbers that move with
+* insertion order, so a secondary index is often built over rows that are
+* already sorted, exactly reversed, or a few ordered batches concatenated.
+*
+* This merges the natural runs instead, which is O(N) on one run and
+* O(N log R) on R of them. Measured against the same inputs:
+*
+* ```text
+*                Hermes native -> runs       V8 native -> runs
+*   sorted         93.2ms -> 5.4ms (17x)     1.0ms -> 0.4ms
+*   reversed      166.6ms -> 6.6ms (25x)     1.0ms -> 0.4ms
+*   20 runs       147.2ms -> 9.4ms (16x)     1.0ms -> 0.8ms
+* ```
+*
+* ## Why it gives up rather than always merging
+*
+* A full TimSort would handle near-sorted input too, but without galloping it
+* loses badly to V8's native sort there (8.0ms against 2.8ms on 100,000
+* near-sorted rows, 1.26M comparisons against 268k), and galloping is a large
+* amount of code to carry. So this returns `undefined` once the input has more
+* runs than merging can pay for, and the caller falls back to whatever it would
+* have done -- which keeps V8's galloping and costs Hermes nothing it was not
+* already paying.
+*
+* ## Where the bound sits, and why it scales
+*
+* Merging R runs costs about `n * log2(R)` comparisons; a non-adaptive sort
+* costs about `n * log2(n)` whatever the input looks like. So merging is worth
+* it exactly while `log2(R)` is the smaller of the two, and `R <= sqrt(n)` is
+* the region where it is at most half -- a bound that needs no fitted constant
+* and tightens on its own as `n` grows. That is what `maxRuns` defaults to,
+* floored at 32 so nothing below 1,024 elements changes.
+*
+* Read the other way round, that bound is a statement about the *input* rather
+* than a tolerance for a number of runs: `R <= sqrt(n)` is the same as saying
+* the average run is at least `sqrt(n)` long. Which is the useful form, because
+* what makes merging pay is runs long enough to amortise a merge pass over, and
+* that does not change when a data set grows. A fixed run count does: the
+* bound was 32 until a table with 50 of something turned up, which is the
+* failure mode this shape avoids.
+*
+* The floor used to be the whole bound, and a fixed 32 was too low to catch the
+* shape this was written for. A secondary index built over a junction table
+* whose primary key leads with the *other* column arrives as one ordered run
+* per distinct value of that column: 50 runs of 1,200 rows over 60,000, for a
+* table with 50 of them. Merging that is O(n log 50), but at `maxRuns` 32 it
+* declined and Hermes fell through to the full non-adaptive sort this function
+* exists to avoid.
+*
+* The bound is deliberately well inside the crossover, and comparisons are not
+* the only cost: merging R runs is `ceil(log2(R))` passes, each writing every
+* element, which an in-place sort does not do. So it was measured past the
+* bound rather than up to it. Sorting 60,000 rows through a three-column
+* comparator on an Android emulator, in a release build, medians of 3 repeats.
+* The engine is Static Hermes 250829098.0.14 -- read out of the APK's
+* `libhermesvm.so` rather than taken from the build config, because what React
+* Native ships is not the engine `sdks/.hermesversion` pins. Hence
+* `libhermesvm.so` and not `libhermes.so`: a different engine, not a later
+* build of the one in the 0.12 table above.
+*
+* Which does not make that table stale, and it is worth being exact about what
+* carries over. Its *comparison counts* reproduce on the shipped engine to the
+* digit -- 1,483,630 sorted and 2,571,203 reversed at 100,000, and 741 at
+* n = 128 -- so the two engines sort by the same algorithm, and the premise all
+* of this rests on holds where it matters: `nativeSortIsAdaptive()` is false on
+* the VM that actually runs, not merely on an old CLI. Its *times* do not carry
+* over, in either direction: those were a standalone CLI on a development host,
+* these are an emulator, and the shipped VM is about 2.3x faster than that CLI
+* on the same host. Compare the counts, never the milliseconds.
+*
+* ```text
+*   runs        native     merge
+*   2          517.9ms    23.0ms
+*   50         218.3ms    82.0ms
+*   100        221.6ms    90.3ms
+*   244        202.8ms   101.4ms   <- the bound at this size
+*   400        210.7ms   110.9ms
+*   1,000      199.4ms   121.5ms
+*   shuffled   221.0ms   207.3ms
+* ```
+*
+* The extra passes do show up -- merging costs five times more at 1,000 runs
+* than at 2 -- but on this engine it still wins everywhere measured, and only
+* on shuffled input does the margin close to nothing. At the bound it is 2x,
+* which is the margin the bound is chosen to keep rather than the point where
+* merging stops paying; a higher one would capture more, and no workload here
+* calls for it. Note also that two ordered runs are the native sort's *worst*
+* case (517.9ms, worse than shuffled), which is the asymmetry this whole
+* function exists to exploit.
+*
+* On V8, which never reaches this path, merging holds level to about 1,000 runs
+* (23.1ms against 24.1ms) and loses past 5,000 and on shuffled input (78.6ms
+* against 43.0ms). That bounds how far merging scales on an adaptive engine; it
+* does not justify the bound, since no caller gets here on one.
+*
+* Declining is not free, and what bounds it is runs, not comparisons: counting
+* stops once a `maxRuns + 1`th run is known to exist, before walking that one,
+* but every run before it is walked to its end. Measured over 100,000 elements
+* with `maxRuns` at 32, against the comparisons the native sort then does:
+*
+* ```text
+*   shuffled                     76 comparisons   0.005%
+*   32 long runs, then more  80,000 comparisons      15%
+* ```
+*
+* Raising the bound raises what a decline can cost, and the shape that pays is
+* an input whose run count lands just past it. Over 60,000 elements in equal
+* ordered runs, comparisons spent before declining:
+*
+* ```text
+*   runs    at bound 32    at bound 244
+*   245          7,840          59,780
+*   400          4,800          36,600
+*   1,000        1,920          14,640
+* ```
+*
+* So a 245-run input now scans essentially the whole array where it used to
+* stop after an eighth of it. What does *not* change is the ceiling: the worst
+* case is `maxRuns` long runs followed by anything at all, and that walks
+* almost every element at either bound -- 60,000 comparisons at 32 against
+* 59,780 at 244. The old bound never bounded the scan below `n`; it only made
+* fewer shapes reach it. Against the non-adaptive sort a decline falls into,
+* which costs about 14.8 comparisons per element on the engine that gets here,
+* a full scan is around 7% on top. (Measured as a fraction of V8's adaptive
+* sort it looks like 17-19%, but nothing reaches this path on V8.)
+*
+* A scan budget cannot be separated from the merge budget without giving up
+* merges that would have won: `R` is only known to exceed the budget once
+* budget-many runs have been seen, and merging `R` runs has to scan all `n`
+* elements regardless. Any limit tight enough to cut a decline short of `n`
+* also rejects inputs just inside the bound, which is the case this change
+* exists to serve.
+*
+* One interaction is worth naming because this bound makes it bigger. The
+* caller in `MemorySource` tries this before its specialised numeric-column
+* pass, so an ordering that the numeric pass could have handled may now pay a
+* scan of up to `n` before taking it anyway. Bounded, and not a shape seen in
+* the ten index builds of a cold pass -- the nine that merge are under 32 runs
+* and the one that declines is string-keyed -- but the chain order is worth
+* revisiting on its own measurement rather than inside a bound change.
+*
+* Of the two rows in the first table, shuffled is the shape that declines in
+* practice, and it gives up almost at once because its runs are two or three
+* elements long. The other is the honest worst case, where the scan walks most
+* of the array before handing it back. Nothing in the
+* workloads this was built for looks like that, but it is what the bound
+* permits, and a caller sorting adversarial input should know it.
+*
+* ## Stability
+*
+* Stable, and that is load-bearing rather than incidental: callers rely on
+* equal elements keeping their input order. Two rules preserve it. Descending
+* runs are detected **strictly**, so equal neighbours are never part of a run
+* that gets reversed; and the merge takes from the earlier run when its head
+* compares equal. The counting pass also does not mutate, so an array handed
+* back on the `undefined` path is untouched -- reversing runs first and then
+* falling back would hand the caller's sort an array whose equal elements had
+* already been reordered, which is how a stable sort quietly stops being one.
+*/
+/**
+* Whether this engine's `Array.prototype.sort` already exploits ordered input,
+* measured rather than guessed from the user agent.
+*
+* Sorting an already-sorted array of `PROBE_SIZE` elements takes exactly
+* `n - 1` comparisons on an adaptive sort and several times that otherwise.
+* Measured at `n = 128`: V8 does 127, Hermes does 741. The threshold below sits
+* between them with a wide margin at every size either engine was tried at.
+*
+* This exists so `sortByNaturalRuns` can be skipped where it cannot win. On V8
+* the native sort is already optimal on ordered input, so run detection only
+* adds a JS pass over data a faster native pass would have walked anyway --
+* measured at a 6% regression on cold-start hydration when applied there
+* unconditionally.
+*
+* The probe runs once, costs a few hundred comparisons, and is deliberately not
+* consulted by `sortByNaturalRuns` itself: callers decide, so the sort stays a
+* pure function that can be tested on whichever engine the tests run on.
+*
+* ## Why this is measured at runtime rather than compiled away
+*
+* The obvious alternative is a build-time flag, so that only the React Native
+* build carries this file at all -- 1,064 bytes minified, 590 gzipped. It was
+* considered and rejected, because "React Native" is a proxy for "Hermes" and
+* is wrong in both directions: React Native can run on JavaScriptCore, as it
+* did by default for years, and Hermes is embedded outside React Native. A
+* build keyed on the former would run the natural-run sort on an engine whose
+* own sort is already adaptive, and doing that is not merely wasted work: it
+* measured a 6.4% regression on cold-start hydration. The probe itself is not
+* what costs anything -- a few hundred comparisons, once: 127 where the native
+* sort is adaptive, 741 on Hermes, which is the one that pays most and the one
+* that gets the 17x back.
+*
+* Measured, sorting 128 already-sorted elements: V8 and JavaScriptCore each do
+* exactly `n - 1` comparisons, Hermes 741. SpiderMonkey was not measured, and
+* that is the argument rather than a hole in it. A hand-maintained list of
+* engines would have to be right about SpiderMonkey, about whatever ships next,
+* and about every embedding of each -- and would be wrong silently. The probe
+* is right about all of them without being told: if SpiderMonkey turns out not
+* to be adaptive, Firefox gets the faster path automatically, and if it is, it
+* never pays for one it does not need.
+*/
+var PROBE_SIZE = 128;
+var adaptive;
+function nativeSortIsAdaptive() {
+	if (adaptive === void 0) {
+		const probe = [];
+		for (let i = 0; i < PROBE_SIZE; i++) probe.push(i);
+		let comparisons = 0;
+		probe.sort((a, b) => {
+			comparisons++;
+			return a - b;
+		});
+		adaptive = comparisons < 256;
+	}
+	return adaptive;
+}
+/**
+* The default run budget for an array of `n` elements: `sqrt(n)`, floored at
+* 32. Integral, because the scan compares its run count against it for
+* equality.
+*/
+function maxRunsFor(n) {
+	return Math.max(32, Math.floor(Math.sqrt(n)));
+}
+/**
+* Sorts `array` in place by merging its natural runs, and returns it.
+*
+* Returns `undefined`, leaving `array` **unmodified**, when it holds more than
+* `maxRuns` runs -- the caller should then sort it however it otherwise would.
+* `maxRuns` defaults to `sqrt(array.length)`, floored at 32; see "Where the
+* bound sits" above.
+*
+* `compare` must be a consistent comparator; results are stable.
+*/
+function sortByNaturalRuns(array, compare, maxRuns = maxRunsFor(array.length)) {
+	const n = array.length;
+	if (n < 2) return array;
+	const starts = [];
+	const descending = [];
+	let i = 0;
+	while (i < n) {
+		if (starts.length >= maxRuns) return;
+		const start = i;
+		let isDescending = false;
+		if (i + 1 < n) {
+			const first = compare(array[i + 1], array[i]);
+			if (first !== first) return;
+			isDescending = first < 0;
+			i += 2;
+			if (isDescending) while (i < n) {
+				const c = compare(array[i], array[i - 1]);
+				if (c !== c) return;
+				if (c >= 0) break;
+				i++;
+			}
+			else while (i < n) {
+				const c = compare(array[i], array[i - 1]);
+				if (c !== c) return;
+				if (c < 0) break;
+				i++;
+			}
+		} else i++;
+		starts.push(start);
+		descending.push(isDescending);
+	}
+	starts.push(n);
+	let runCount = descending.length;
+	if (runCount === 1) {
+		if (descending[0]) reverse(array, 0, n - 1);
+		return array;
+	}
+	let src = array.slice();
+	let dst = new Array(n);
+	let bounds = starts;
+	for (let r = 0; r < runCount; r++) if (descending[r]) reverse(src, starts[r], starts[r + 1] - 1);
+	while (runCount > 1) {
+		const nextBounds = [0];
+		let write = 0;
+		let merged = 0;
+		for (let p = 0; p < runCount; p += 2) {
+			let a = bounds[p];
+			const endA = bounds[p + 1];
+			if (p + 1 >= runCount) while (a < endA) dst[write++] = src[a++];
+			else {
+				let b = bounds[p + 1];
+				const endB = bounds[p + 2];
+				while (a < endA && b < endB) {
+					const c = compare(src[b], src[a]);
+					if (c !== c) return;
+					dst[write++] = c < 0 ? src[b++] : src[a++];
+				}
+				while (a < endA) dst[write++] = src[a++];
+				while (b < endB) dst[write++] = src[b++];
+			}
+			merged++;
+			nextBounds.push(write);
+		}
+		const swap = src;
+		src = dst;
+		dst = swap;
+		bounds = nextBounds;
+		runCount = merged;
+	}
+	for (let c = 0; c < n; c++) array[c] = src[c];
+	return array;
+}
+function reverse(array, lo, hi) {
+	while (lo < hi) {
+		const t = array[lo];
+		array[lo++] = array[hi];
+		array[hi--] = t;
+	}
+}
+//#endregion
+export { nativeSortIsAdaptive, sortByNaturalRuns };
+
+//# sourceMappingURL=natural-runs.js.map

package/out/shared/src/natural-runs.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"natural-runs.js","names":[],"sources":["../../../../shared/src/natural-runs.ts"],"sourcesContent":["/**\n * A stable sort for input that already arrives in a handful of ordered runs,\n * for the engines whose built-in sort cannot exploit that.\n *\n * `Array.prototype.sort` is TimSort on V8, so already-sorted input costs N-1\n * comparisons. **On Hermes it is not adaptive**, and the difference is not\n * small. Sorting 100,000 objects through a two-column comparator:\n *\n * ```text\n *                Hermes 0.12                V8\n *   sorted     93.6ms / 1,483,630      0.8ms / 99,999\n *   reversed  168.6ms / 2,571,203      0.8ms / 99,999\n *   shuffled  134.8ms / 1,770,233     17.0ms / 1,529,373\n * ```\n *\n * Hermes does fifteen times the necessary comparisons on sorted input, and\n * reversed input is its *worst* case -- slower than random data, where an O(N)\n * reverse would do. That matters because ordered input is the common case here\n * and not a lucky one: rows come out of a source in primary-key order, and\n * secondary sort keys are usually timestamps or sequence numbers that move with\n * insertion order, so a secondary index is often built over rows that are\n * already sorted, exactly reversed, or a few ordered batches concatenated.\n *\n * This merges the natural runs instead, which is O(N) on one run and\n * O(N log R) on R of them. Measured against the same inputs:\n *\n * ```text\n *                Hermes native -> runs       V8 native -> runs\n *   sorted         93.2ms -> 5.4ms (17x)     1.0ms -> 0.4ms\n *   reversed      166.6ms -> 6.6ms (25x)     1.0ms -> 0.4ms\n *   20 runs       147.2ms -> 9.4ms (16x)     1.0ms -> 0.8ms\n * ```\n *\n * ## Why it gives up rather than always merging\n *\n * A full TimSort would handle near-sorted input too, but without galloping it\n * loses badly to V8's native sort there (8.0ms against 2.8ms on 100,000\n * near-sorted rows, 1.26M comparisons against 268k), and galloping is a large\n * amount of code to carry. So this returns `undefined` once the input has more\n * runs than merging can pay for, and the caller falls back to whatever it would\n * have done -- which keeps V8's galloping and costs Hermes nothing it was not\n * already paying.\n *\n * ## Where the bound sits, and why it scales\n *\n * Merging R runs costs about `n * log2(R)` comparisons; a non-adaptive sort\n * costs about `n * log2(n)` whatever the input looks like. So merging is worth\n * it exactly while `log2(R)` is the smaller of the two, and `R <= sqrt(n)` is\n * the region where it is at most half -- a bound that needs no fitted constant\n * and tightens on its own as `n` grows. That is what `maxRuns` defaults to,\n * floored at 32 so nothing below 1,024 elements changes.\n *\n * Read the other way round, that bound is a statement about the *input* rather\n * than a tolerance for a number of runs: `R <= sqrt(n)` is the same as saying\n * the average run is at least `sqrt(n)` long. Which is the useful form, because\n * what makes merging pay is runs long enough to amortise a merge pass over, and\n * that does not change when a data set grows. A fixed run count does: the\n * bound was 32 until a table with 50 of something turned up, which is the\n * failure mode this shape avoids.\n *\n * The floor used to be the whole bound, and a fixed 32 was too low to catch the\n * shape this was written for. A secondary index built over a junction table\n * whose primary key leads with the *other* column arrives as one ordered run\n * per distinct value of that column: 50 runs of 1,200 rows over 60,000, for a\n * table with 50 of them. Merging that is O(n log 50), but at `maxRuns` 32 it\n * declined and Hermes fell through to the full non-adaptive sort this function\n * exists to avoid.\n *\n * The bound is deliberately well inside the crossover, and comparisons are not\n * the only cost: merging R runs is `ceil(log2(R))` passes, each writing every\n * element, which an in-place sort does not do. So it was measured past the\n * bound rather than up to it. Sorting 60,000 rows through a three-column\n * comparator on an Android emulator, in a release build, medians of 3 repeats.\n * The engine is Static Hermes 250829098.0.14 -- read out of the APK's\n * `libhermesvm.so` rather than taken from the build config, because what React\n * Native ships is not the engine `sdks/.hermesversion` pins. Hence\n * `libhermesvm.so` and not `libhermes.so`: a different engine, not a later\n * build of the one in the 0.12 table above.\n *\n * Which does not make that table stale, and it is worth being exact about what\n * carries over. Its *comparison counts* reproduce on the shipped engine to the\n * digit -- 1,483,630 sorted and 2,571,203 reversed at 100,000, and 741 at\n * n = 128 -- so the two engines sort by the same algorithm, and the premise all\n * of this rests on holds where it matters: `nativeSortIsAdaptive()` is false on\n * the VM that actually runs, not merely on an old CLI. Its *times* do not carry\n * over, in either direction: those were a standalone CLI on a development host,\n * these are an emulator, and the shipped VM is about 2.3x faster than that CLI\n * on the same host. Compare the counts, never the milliseconds.\n *\n * ```text\n *   runs        native     merge\n *   2          517.9ms    23.0ms\n *   50         218.3ms    82.0ms\n *   100        221.6ms    90.3ms\n *   244        202.8ms   101.4ms   <- the bound at this size\n *   400        210.7ms   110.9ms\n *   1,000      199.4ms   121.5ms\n *   shuffled   221.0ms   207.3ms\n * ```\n *\n * The extra passes do show up -- merging costs five times more at 1,000 runs\n * than at 2 -- but on this engine it still wins everywhere measured, and only\n * on shuffled input does the margin close to nothing. At the bound it is 2x,\n * which is the margin the bound is chosen to keep rather than the point where\n * merging stops paying; a higher one would capture more, and no workload here\n * calls for it. Note also that two ordered runs are the native sort's *worst*\n * case (517.9ms, worse than shuffled), which is the asymmetry this whole\n * function exists to exploit.\n *\n * On V8, which never reaches this path, merging holds level to about 1,000 runs\n * (23.1ms against 24.1ms) and loses past 5,000 and on shuffled input (78.6ms\n * against 43.0ms). That bounds how far merging scales on an adaptive engine; it\n * does not justify the bound, since no caller gets here on one.\n *\n * Declining is not free, and what bounds it is runs, not comparisons: counting\n * stops once a `maxRuns + 1`th run is known to exist, before walking that one,\n * but every run before it is walked to its end. Measured over 100,000 elements\n * with `maxRuns` at 32, against the comparisons the native sort then does:\n *\n * ```text\n *   shuffled                     76 comparisons   0.005%\n *   32 long runs, then more  80,000 comparisons      15%\n * ```\n *\n * Raising the bound raises what a decline can cost, and the shape that pays is\n * an input whose run count lands just past it. Over 60,000 elements in equal\n * ordered runs, comparisons spent before declining:\n *\n * ```text\n *   runs    at bound 32    at bound 244\n *   245          7,840          59,780\n *   400          4,800          36,600\n *   1,000        1,920          14,640\n * ```\n *\n * So a 245-run input now scans essentially the whole array where it used to\n * stop after an eighth of it. What does *not* change is the ceiling: the worst\n * case is `maxRuns` long runs followed by anything at all, and that walks\n * almost every element at either bound -- 60,000 comparisons at 32 against\n * 59,780 at 244. The old bound never bounded the scan below `n`; it only made\n * fewer shapes reach it. Against the non-adaptive sort a decline falls into,\n * which costs about 14.8 comparisons per element on the engine that gets here,\n * a full scan is around 7% on top. (Measured as a fraction of V8's adaptive\n * sort it looks like 17-19%, but nothing reaches this path on V8.)\n *\n * A scan budget cannot be separated from the merge budget without giving up\n * merges that would have won: `R` is only known to exceed the budget once\n * budget-many runs have been seen, and merging `R` runs has to scan all `n`\n * elements regardless. Any limit tight enough to cut a decline short of `n`\n * also rejects inputs just inside the bound, which is the case this change\n * exists to serve.\n *\n * One interaction is worth naming because this bound makes it bigger. The\n * caller in `MemorySource` tries this before its specialised numeric-column\n * pass, so an ordering that the numeric pass could have handled may now pay a\n * scan of up to `n` before taking it anyway. Bounded, and not a shape seen in\n * the ten index builds of a cold pass -- the nine that merge are under 32 runs\n * and the one that declines is string-keyed -- but the chain order is worth\n * revisiting on its own measurement rather than inside a bound change.\n *\n * Of the two rows in the first table, shuffled is the shape that declines in\n * practice, and it gives up almost at once because its runs are two or three\n * elements long. The other is the honest worst case, where the scan walks most\n * of the array before handing it back. Nothing in the\n * workloads this was built for looks like that, but it is what the bound\n * permits, and a caller sorting adversarial input should know it.\n *\n * ## Stability\n *\n * Stable, and that is load-bearing rather than incidental: callers rely on\n * equal elements keeping their input order. Two rules preserve it. Descending\n * runs are detected **strictly**, so equal neighbours are never part of a run\n * that gets reversed; and the merge takes from the earlier run when its head\n * compares equal. The counting pass also does not mutate, so an array handed\n * back on the `undefined` path is untouched -- reversing runs first and then\n * falling back would hand the caller's sort an array whose equal elements had\n * already been reordered, which is how a stable sort quietly stops being one.\n */\n\n/**\n * Whether this engine's `Array.prototype.sort` already exploits ordered input,\n * measured rather than guessed from the user agent.\n *\n * Sorting an already-sorted array of `PROBE_SIZE` elements takes exactly\n * `n - 1` comparisons on an adaptive sort and several times that otherwise.\n * Measured at `n = 128`: V8 does 127, Hermes does 741. The threshold below sits\n * between them with a wide margin at every size either engine was tried at.\n *\n * This exists so `sortByNaturalRuns` can be skipped where it cannot win. On V8\n * the native sort is already optimal on ordered input, so run detection only\n * adds a JS pass over data a faster native pass would have walked anyway --\n * measured at a 6% regression on cold-start hydration when applied there\n * unconditionally.\n *\n * The probe runs once, costs a few hundred comparisons, and is deliberately not\n * consulted by `sortByNaturalRuns` itself: callers decide, so the sort stays a\n * pure function that can be tested on whichever engine the tests run on.\n *\n * ## Why this is measured at runtime rather than compiled away\n *\n * The obvious alternative is a build-time flag, so that only the React Native\n * build carries this file at all -- 1,064 bytes minified, 590 gzipped. It was\n * considered and rejected, because \"React Native\" is a proxy for \"Hermes\" and\n * is wrong in both directions: React Native can run on JavaScriptCore, as it\n * did by default for years, and Hermes is embedded outside React Native. A\n * build keyed on the former would run the natural-run sort on an engine whose\n * own sort is already adaptive, and doing that is not merely wasted work: it\n * measured a 6.4% regression on cold-start hydration. The probe itself is not\n * what costs anything -- a few hundred comparisons, once: 127 where the native\n * sort is adaptive, 741 on Hermes, which is the one that pays most and the one\n * that gets the 17x back.\n *\n * Measured, sorting 128 already-sorted elements: V8 and JavaScriptCore each do\n * exactly `n - 1` comparisons, Hermes 741. SpiderMonkey was not measured, and\n * that is the argument rather than a hole in it. A hand-maintained list of\n * engines would have to be right about SpiderMonkey, about whatever ships next,\n * and about every embedding of each -- and would be wrong silently. The probe\n * is right about all of them without being told: if SpiderMonkey turns out not\n * to be adaptive, Firefox gets the faster path automatically, and if it is, it\n * never pays for one it does not need.\n */\nconst PROBE_SIZE = 128;\n\nlet adaptive: boolean | undefined;\n\nexport function nativeSortIsAdaptive(): boolean {\n  if (adaptive === undefined) {\n    const probe: number[] = [];\n    for (let i = 0; i < PROBE_SIZE; i++) {\n      probe.push(i);\n    }\n    let comparisons = 0;\n    probe.sort((a, b) => {\n      comparisons++;\n      return a - b;\n    });\n    adaptive = comparisons < PROBE_SIZE * 2;\n  }\n  return adaptive;\n}\n\n/**\n * The default run budget for an array of `n` elements: `sqrt(n)`, floored at\n * 32. Integral, because the scan compares its run count against it for\n * equality.\n */\nfunction maxRunsFor(n: number): number {\n  return Math.max(32, Math.floor(Math.sqrt(n)));\n}\n\n/**\n * Sorts `array` in place by merging its natural runs, and returns it.\n *\n * Returns `undefined`, leaving `array` **unmodified**, when it holds more than\n * `maxRuns` runs -- the caller should then sort it however it otherwise would.\n * `maxRuns` defaults to `sqrt(array.length)`, floored at 32; see \"Where the\n * bound sits\" above.\n *\n * `compare` must be a consistent comparator; results are stable.\n */\nexport function sortByNaturalRuns<T>(\n  array: T[],\n  compare: (a: T, b: T) => number,\n  maxRuns = maxRunsFor(array.length),\n): T[] | undefined {\n  const n = array.length;\n  if (n < 2) {\n    return array;\n  }\n\n  // Pass one, which must not mutate: where each run starts, and whether it is\n  // descending and so needs reversing before it can be merged.\n  const starts: number[] = [];\n  const descending: boolean[] = [];\n  let i = 0;\n  while (i < n) {\n    // Stop before walking another run once `maxRuns` are already in hand and\n    // input is left: this call cannot succeed now, and the next run could be\n    // the whole remainder of the array.\n    if (starts.length >= maxRuns) {\n      return undefined;\n    }\n    const start = i;\n    let isDescending = false;\n    if (i + 1 < n) {\n      const first = compare(array[i + 1], array[i]);\n      // `c !== c` is a NaN test without a call. A comparator that returns NaN\n      // is not an ordering -- it is not even antisymmetric -- so runs and\n      // merges are meaningless and, worse, would silently disagree with the\n      // caller's own sort: `compareValues` yields NaN for a NaN sort key, and\n      // for the values `[1, NaN, 0]` a native sort leaves them alone while\n      // merging produces `[0, 1, NaN]`. Decline and let the caller's sort\n      // decide, so whatever it does today it keeps doing.\n      //\n      // This catches a NaN only where this pass happens to compare the key\n      // holding it. A multi-column comparator short-circuits on the first\n      // differing column, so a NaN in a later column stays invisible here and\n      // first surfaces during the merge, which compares rows this pass never\n      // put side by side. The merge checks too, and the merge path works on a\n      // copy so that it can still decline when it does.\n      if (first !== first) {\n        return undefined;\n      }\n      isDescending = first < 0;\n      i += 2;\n      if (isDescending) {\n        // Strictly descending: a run containing equal neighbours must not be\n        // reversed, or their relative order would flip.\n        while (i < n) {\n          const c = compare(array[i], array[i - 1]);\n          if (c !== c) {\n            return undefined;\n          }\n          if (c >= 0) {\n            break;\n          }\n          i++;\n        }\n      } else {\n        while (i < n) {\n          const c = compare(array[i], array[i - 1]);\n          if (c !== c) {\n            return undefined;\n          }\n          if (c < 0) {\n            break;\n          }\n          i++;\n        }\n      }\n    } else {\n      i++;\n    }\n    starts.push(start);\n    descending.push(isDescending);\n  }\n  starts.push(n);\n\n  let runCount = descending.length;\n  if (runCount === 1) {\n    // One run means no merge, so no comparison beyond the ones already made:\n    // nothing further can surface a NaN, and there is nothing to undo. This is\n    // also the case worth the most -- already-sorted and exactly-reversed input\n    // -- so it stays free of the copy the merge path needs.\n    if (descending[0]) {\n      reverse(array, 0, n - 1);\n    }\n    return array;\n  }\n\n  // From here the merge compares rows the counting pass never put side by side,\n  // which is where a NaN in a later ordering column can first appear. Declining\n  // at that point has to leave `array` exactly as it was, so the work happens on\n  // a copy and is written back only once it has succeeded.\n  let src = array.slice();\n  // Pre-sized on purpose: it is filled by index below, and `Array.from` would\n  // allocate and then fill it twice.\n  // oxlint-disable-next-line unicorn/no-new-array\n  let dst = new Array<T>(n);\n  let bounds = starts;\n\n  for (let r = 0; r < runCount; r++) {\n    if (descending[r]) {\n      reverse(src, starts[r], starts[r + 1] - 1);\n    }\n  }\n  while (runCount > 1) {\n    const nextBounds: number[] = [0];\n    let write = 0;\n    let merged = 0;\n    for (let p = 0; p < runCount; p += 2) {\n      let a = bounds[p];\n      const endA = bounds[p + 1];\n      if (p + 1 >= runCount) {\n        while (a < endA) {\n          dst[write++] = src[a++];\n        }\n      } else {\n        let b = bounds[p + 1];\n        const endB = bounds[p + 2];\n        while (a < endA && b < endB) {\n          const c = compare(src[b], src[a]);\n          if (c !== c) {\n            // A NaN the counting pass could not see. `array` has not been\n            // written, so handing it back untouched is still possible.\n            return undefined;\n          }\n          // `< 0` and not `<= 0`: on a tie the earlier run wins, which is what\n          // keeps this stable.\n          dst[write++] = c < 0 ? src[b++] : src[a++];\n        }\n        while (a < endA) {\n          dst[write++] = src[a++];\n        }\n        while (b < endB) {\n          dst[write++] = src[b++];\n        }\n      }\n      merged++;\n      nextBounds.push(write);\n    }\n    const swap = src;\n    src = dst;\n    dst = swap;\n    bounds = nextBounds;\n    runCount = merged;\n  }\n\n  for (let c = 0; c < n; c++) {\n    array[c] = src[c];\n  }\n  return array;\n}\n\nfunction reverse<T>(array: T[], lo: number, hi: number): void {\n  while (lo < hi) {\n    const t = array[lo];\n    array[lo++] = array[hi];\n    array[hi--] = t;\n  }\n}\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AA6NA,IAAM,aAAa;AAEnB,IAAI;AAEJ,SAAgB,uBAAgC;CAC9C,IAAI,aAAa,KAAA,GAAW;EAC1B,MAAM,QAAkB,CAAC;EACzB,KAAK,IAAI,IAAI,GAAG,IAAI,YAAY,KAC9B,MAAM,KAAK,CAAC;EAEd,IAAI,cAAc;EAClB,MAAM,MAAM,GAAG,MAAM;GACnB;GACA,OAAO,IAAI;EACb,CAAC;EACD,WAAW,cAAc;CAC3B;CACA,OAAO;AACT;;;;;;AAOA,SAAS,WAAW,GAAmB;CACrC,OAAO,KAAK,IAAI,IAAI,KAAK,MAAM,KAAK,KAAK,CAAC,CAAC,CAAC;AAC9C;;;;;;;;;;;AAYA,SAAgB,kBACd,OACA,SACA,UAAU,WAAW,MAAM,MAAM,GAChB;CACjB,MAAM,IAAI,MAAM;CAChB,IAAI,IAAI,GACN,OAAO;CAKT,MAAM,SAAmB,CAAC;CAC1B,MAAM,aAAwB,CAAC;CAC/B,IAAI,IAAI;CACR,OAAO,IAAI,GAAG;EAIZ,IAAI,OAAO,UAAU,SACnB;EAEF,MAAM,QAAQ;EACd,IAAI,eAAe;EACnB,IAAI,IAAI,IAAI,GAAG;GACb,MAAM,QAAQ,QAAQ,MAAM,IAAI,IAAI,MAAM,EAAE;GAe5C,IAAI,UAAU,OACZ;GAEF,eAAe,QAAQ;GACvB,KAAK;GACL,IAAI,cAGF,OAAO,IAAI,GAAG;IACZ,MAAM,IAAI,QAAQ,MAAM,IAAI,MAAM,IAAI,EAAE;IACxC,IAAI,MAAM,GACR;IAEF,IAAI,KAAK,GACP;IAEF;GACF;QAEA,OAAO,IAAI,GAAG;IACZ,MAAM,IAAI,QAAQ,MAAM,IAAI,MAAM,IAAI,EAAE;IACxC,IAAI,MAAM,GACR;IAEF,IAAI,IAAI,GACN;IAEF;GACF;EAEJ,OACE;EAEF,OAAO,KAAK,KAAK;EACjB,WAAW,KAAK,YAAY;CAC9B;CACA,OAAO,KAAK,CAAC;CAEb,IAAI,WAAW,WAAW;CAC1B,IAAI,aAAa,GAAG;EAKlB,IAAI,WAAW,IACb,QAAQ,OAAO,GAAG,IAAI,CAAC;EAEzB,OAAO;CACT;CAMA,IAAI,MAAM,MAAM,MAAM;CAItB,IAAI,MAAM,IAAI,MAAS,CAAC;CACxB,IAAI,SAAS;CAEb,KAAK,IAAI,IAAI,GAAG,IAAI,UAAU,KAC5B,IAAI,WAAW,IACb,QAAQ,KAAK,OAAO,IAAI,OAAO,IAAI,KAAK,CAAC;CAG7C,OAAO,WAAW,GAAG;EACnB,MAAM,aAAuB,CAAC,CAAC;EAC/B,IAAI,QAAQ;EACZ,IAAI,SAAS;EACb,KAAK,IAAI,IAAI,GAAG,IAAI,UAAU,KAAK,GAAG;GACpC,IAAI,IAAI,OAAO;GACf,MAAM,OAAO,OAAO,IAAI;GACxB,IAAI,IAAI,KAAK,UACX,OAAO,IAAI,MACT,IAAI,WAAW,IAAI;QAEhB;IACL,IAAI,IAAI,OAAO,IAAI;IACnB,MAAM,OAAO,OAAO,IAAI;IACxB,OAAO,IAAI,QAAQ,IAAI,MAAM;KAC3B,MAAM,IAAI,QAAQ,IAAI,IAAI,IAAI,EAAE;KAChC,IAAI,MAAM,GAGR;KAIF,IAAI,WAAW,IAAI,IAAI,IAAI,OAAO,IAAI;IACxC;IACA,OAAO,IAAI,MACT,IAAI,WAAW,IAAI;IAErB,OAAO,IAAI,MACT,IAAI,WAAW,IAAI;GAEvB;GACA;GACA,WAAW,KAAK,KAAK;EACvB;EACA,MAAM,OAAO;EACb,MAAM;EACN,MAAM;EACN,SAAS;EACT,WAAW;CACb;CAEA,KAAK,IAAI,IAAI,GAAG,IAAI,GAAG,KACrB,MAAM,KAAK,IAAI;CAEjB,OAAO;AACT;AAEA,SAAS,QAAW,OAAY,IAAY,IAAkB;CAC5D,OAAO,KAAK,IAAI;EACd,MAAM,IAAI,MAAM;EAChB,MAAM,QAAQ,MAAM;EACpB,MAAM,QAAQ;CAChB;AACF"}

package/out/shared/src/random-uint64.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"random-uint64.d.ts","sourceRoot":"","sources":["../../../../shared/src/random-uint64.ts"],"names":[],"mappings":"AAAA,wBAAgB,YAAY,IAAI,MAAM,CAOrC"}
+{"version":3,"file":"random-uint64.d.ts","sourceRoot":"","sources":["../../../../shared/src/random-uint64.ts"],"names":[],"mappings":"AAEA,wBAAgB,YAAY,IAAI,MAAM,CAKrC"}

package/out/shared/src/random-uint64.js

@@ -1,7 +1,7 @@
+import { getRandomValues } from "./random-values.js";
 //#region ../shared/src/random-uint64.ts
 function randomUint64() {
-	const high = Math.floor(Math.random() * 4294967295);
-	const low = Math.floor(Math.random() * 4294967295);
+	const [high, low] = getRandomValues(/* @__PURE__ */ new Uint32Array(2));
 	return BigInt(high) << 32n | BigInt(low);
 }
 //#endregion

package/out/shared/src/random-uint64.js.map

@@ -1 +1 @@
-{"version":3,"file":"random-uint64.js","names":[],"sources":["../../../../shared/src/random-uint64.ts"],"sourcesContent":["export function randomUint64(): bigint {\n  // Generate two random 32-bit unsigned integers using Math.random()\n  const high = Math.floor(Math.random() * 0xffffffff); // High 32 bits\n  const low = Math.floor(Math.random() * 0xffffffff); // Low 32 bits\n\n  // Combine the high and low parts to form a 64-bit unsigned integer\n  return (BigInt(high) << 32n) | BigInt(low);\n}\n"],"mappings":";AAAA,SAAgB,eAAuB;CAErC,MAAM,OAAO,KAAK,MAAM,KAAK,OAAO,IAAI,UAAU;CAClD,MAAM,MAAM,KAAK,MAAM,KAAK,OAAO,IAAI,UAAU;CAGjD,OAAQ,OAAO,IAAI,KAAK,MAAO,OAAO,GAAG;AAC3C"}
+{"version":3,"file":"random-uint64.js","names":[],"sources":["../../../../shared/src/random-uint64.ts"],"sourcesContent":["import {getRandomValues} from './random-values.ts';\n\nexport function randomUint64(): bigint {\n  // Two random 32-bit words rather than a BigUint64Array, which Hermes did\n  // not have as of September 2024. The result is the same either way.\n  const [high, low] = getRandomValues(new Uint32Array(2));\n  return (BigInt(high) << 32n) | BigInt(low);\n}\n"],"mappings":";;AAEA,SAAgB,eAAuB;CAGrC,MAAM,CAAC,MAAM,OAAO,gCAAgB,IAAI,YAAY,CAAC,CAAC;CACtD,OAAQ,OAAO,IAAI,KAAK,MAAO,OAAO,GAAG;AAC3C"}

package/out/shared/src/random-values.d.ts

@@ -1,3 +1,21 @@
-export declare function getNonCryptoRandomValues(array: Uint8Array): Uint8Array<ArrayBufferLike>;
+type RandomArray = Uint8Array<ArrayBuffer> | Uint32Array<ArrayBuffer>;
+/**
+ * Fills `array` with random values. Uses `crypto.getRandomValues` when the
+ * runtime provides it, then the native `ExpoCrypto` module when running in an
+ * Expo app, and falls back to `Math.random` otherwise, logging a warning the
+ * first time the fallback is used.
+ *
+ * React Native's Hermes engine has no WebCrypto. Expo installs its native
+ * modules on `globalThis.expo.modules`, and `ExpoCrypto` is there in Expo Go
+ * and in any app that has `expo-crypto` installed, even if the app never
+ * imports it. Other React Native apps should import a polyfill such as
+ * `react-native-get-random-values` before creating IDs.
+ *
+ * The globals are looked up on every call rather than at module load: some
+ * runtimes (e.g. Cloudflare Workers) only allow generating random values
+ * while handling a request.
+ */
+export declare function getRandomValues<T extends RandomArray>(array: T): T;
 export declare function randomCharacters(length: number): string;
+export {};
 //# sourceMappingURL=random-values.d.ts.map

package/out/shared/src/random-values.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"random-values.d.ts","sourceRoot":"","sources":["../../../../shared/src/random-values.ts"],"names":[],"mappings":"AAAA,wBAAgB,wBAAwB,CAAC,KAAK,EAAE,UAAU,+BAWzD;AAED,wBAAgB,gBAAgB,CAAC,MAAM,EAAE,MAAM,UAW9C"}
+{"version":3,"file":"random-values.d.ts","sourceRoot":"","sources":["../../../../shared/src/random-values.ts"],"names":[],"mappings":"AAEA,KAAK,WAAW,GAAG,UAAU,CAAC,WAAW,CAAC,GAAG,WAAW,CAAC,WAAW,CAAC,CAAC;AAgBtE;;;;;;;;;;;;;;;GAeG;AACH,wBAAgB,eAAe,CAAC,CAAC,SAAS,WAAW,EAAE,KAAK,EAAE,CAAC,GAAG,CAAC,CAuBlE;AAgBD,wBAAgB,gBAAgB,CAAC,MAAM,EAAE,MAAM,UAW9C"}