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

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.6";
 
 /**
  * `HttpClient` — the one place the unified {@link Client} talks to the
@@ -7653,11 +7653,21 @@ 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, 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.
+        //
+        // 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.
+        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 +12162,12 @@ 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.
+ *
+ *  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. */
+const WALK_CONCURRENCY = 8;
 /**
  * `Promise.all` with a ceiling, preserving input order.
  *