@muhkoo/connect 0.14.0-alpha.6 → 0.14.0-alpha.7

package/dist/server/index.js

@@ -3235,7 +3235,7 @@ function base64UrlDecode(s) {
  * expect (and isn't serving a stale cached bundle). Keep this in sync with
  * `package.json` `version`.
  */
-const VERSION = "0.14.0-alpha.6";
+const VERSION = "0.14.0-alpha.7";
 
 /**
  * `HttpClient` — the one place the unified {@link Client} talks to the
@@ -7656,17 +7656,20 @@ class FileStorage {
         // Shard reads coalesce into batches, so this is not a cap on requests —
         // it is how many hashes are available to batch together.
         //
-        // 8, not 16, and that is measured rather than reasoned. Raising it to 16
-        // (with the walk at 24) made a 519-file project load SLOWER: median 18.4s
-        // against 14.9s over three runs each. More hashes pending fills batches
-        // closer to the 256 cap, and a bigger batch is one large payload that has
-        // to arrive and decode completely before ANY of its files resolve — so
-        // the extra concurrency buys chunkier round trips with less overlap
-        // rather than more parallelism.
+        // 8 because nothing measurable argues for more.
         //
-        // There is a floor as well as a ceiling: too low and each batch is small
-        // and serial, which is worse than not batching at all. 8 sits between the
-        // two, and moving it in either direction should be measured, not argued.
+        // Raising it to 16 (walk at 24) looked 23% slower over three runs each,
+        // and reverting looked like it restored the win — until a third set of
+        // three landed on the same numbers as the RAISED setting. Pooled, the
+        // configurations are indistinguishable: the run-to-run spread on a
+        // 519-file project is 13.9-20.9s, far wider than any difference between
+        // them. Three samples could not have resolved it and should not have
+        // been trusted to.
+        //
+        // What IS established is the floor: too low and each batch is small and
+        // serial, which is worse than not batching at all. Above that the setting
+        // stops mattering at this scale, so it stays at the simpler value. Moving
+        // it needs a sample large enough to see past that spread.
         this.concurrency = Math.max(1, opts.concurrency ?? 8);
         this.rsWasmModule = opts.rsWasmModule;
         if (this.chunkSize < 1)
@@ -12164,9 +12167,10 @@ const MAX_DEPTH = 64;
  */
 /** Directory records fetched in parallel while walking.
  *
- *  Back to 8 with the shard read concurrency: raising both together measured
- *  SLOWER on a 519-file project (median 18.4s against 14.9s), because fuller
- *  batches are chunkier round trips rather than more parallelism. */
+ *  Kept at 8 alongside the shard read concurrency. Raising both to 24/16 was
+ *  neither better nor worse once enough samples were taken — the spread between
+ *  runs is wider than the difference between the settings — so this stays at the
+ *  simpler value. See FileStorage's note. */
 const WALK_CONCURRENCY = 8;
 /**
  * `Promise.all` with a ceiling, preserving input order.