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

package/dist/browser/index.js

@@ -4242,7 +4242,11 @@ class FileStorage {
         this.chunkSize = opts.chunkSize ?? 4 * 1024 * 1024;
         this.dataShards = opts.dataShards ?? 4;
         this.parityShards = opts.parityShards ?? 2;
-        this.concurrency = Math.max(1, opts.concurrency ?? 8);
+        // 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);
         this.rsWasmModule = opts.rsWasmModule;
         if (this.chunkSize < 1)
             throw new Error("FileStorage: chunkSize must be >= 1 byte");
@@ -5496,7 +5500,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.4";
+const VERSION = "0.14.0-alpha.5";
 
 /**
  * `HttpClient` — the one place the unified {@link Client} talks to the
@@ -12417,7 +12421,10 @@ 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.
  */
-const WALK_CONCURRENCY = 8;
+/** 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;
 /**
  * `Promise.all` with a ceiling, preserving input order.
  *