@muhkoo/connect 0.14.0-alpha.5 → 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.5";
+const VERSION = "0.14.0-alpha.7";
 
 /**
  * `HttpClient` — the one place the unified {@link Client} talks to the
@@ -7653,11 +7653,24 @@ class FileStorage {
         this.chunkSize = opts.chunkSize ?? 4 * 1024 * 1024;
         this.dataShards = opts.dataShards ?? 4;
         this.parityShards = opts.parityShards ?? 2;
-        // Shard reads coalesce into batches, so this is no longer a cap on
-        // requests — it is how many hashes are available to batch together. Too
-        // low and each batch is small and serial, which is strictly worse than
-        // not batching at all.
-        this.concurrency = Math.max(1, opts.concurrency ?? 16);
+        // Shard reads coalesce into batches, so this is not a cap on requests —
+        // it is how many hashes are available to batch together.
+        //
+        // 8 because nothing measurable argues for more.
+        //
+        // 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)
             throw new Error("FileStorage: chunkSize must be >= 1 byte");
@@ -12152,10 +12165,13 @@ const MAX_DEPTH = 64;
  * project does not open a request per directory. Browsers cap concurrency per
  * origin anyway, so a larger number mostly moves the queue.
  */
-/** Directory records fetched in parallel while walking. Raised alongside the
- *  shard read concurrency: the walk is what discovers the files whose shards
- *  then batch together, so a narrow walk throttles everything downstream. */
-const WALK_CONCURRENCY = 24;
+/** Directory records fetched in parallel while walking.
+ *
+ *  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.
  *