perf: Improve UI responsiveness during large sync audits

kilbot · kilbot · commit 8657e1fc6e7a · 2026-01-27T23:41:25.000+01:00
sync-state.ts:
- Reduce chunk size from 5000 to 500 for new record inserts
- Add progress logging for large datasets (&gt;5000 records)
- Yield after every chunk (not just between chunks)

yield.ts:
- Use scheduler.yield() when available (Chrome 115+)
- Fall back to setTimeout(0) instead of requestAnimationFrame
- rAF only fires once per frame (~16ms) which is too slow for
  data processing; setTimeout(0) allows more frequent yields

This should significantly improve UI responsiveness when syncing
large datasets (e.g., 25k orders) by breaking work into smaller
chunks and yielding more frequently.
diff --git a/packages/query/src/sync-state.ts b/packages/query/src/sync-state.ts
@@ -176,15 +176,31 @@ export class SyncStateManager {
 			}));
 
 		if (newRecords.length > 0) {
-			// Process new records in chunks with yielding for very large sets
-			const newRecordChunkSize = 5000;
+			// Process new records in small chunks with yielding to keep UI responsive
+			// Smaller chunks = more yields = smoother UI, but slightly slower overall
+			// 500 is a good balance for IndexedDB writes
+			const newRecordChunkSize = 500;
+			const totalChunks = Math.ceil(newRecords.length / newRecordChunkSize);
+
 			for (let i = 0; i < newRecords.length; i += newRecordChunkSize) {
 				const chunk = newRecords.slice(i, i + newRecordChunkSize);
 				await this.syncCollection.bulkUpsert(chunk);
 
-				// Yield between chunks
-				if (i + newRecordChunkSize < newRecords.length) {
-					await yieldToEventLoop();
+				// Yield after every chunk to keep UI responsive
+				await yieldToEventLoop();
+
+				// Log progress for large sets
+				if (newRecords.length > 5000) {
+					const chunkNum = Math.floor(i / newRecordChunkSize) + 1;
+					if (chunkNum % 10 === 0 || chunkNum === totalChunks) {
+						syncLogger.debug(`Audit progress: ${chunkNum}/${totalChunks} chunks`, {
+							context: {
+								endpoint: this.endpoint,
+								processed: Math.min(i + newRecordChunkSize, newRecords.length),
+								total: newRecords.length,
+							},
+						});
+					}
 				}
 			}
 		}
diff --git a/packages/query/src/yield.ts b/packages/query/src/yield.ts
@@ -2,7 +2,12 @@
  * Yields execution to allow the event loop to process other tasks.
  *
  * This prevents UI blocking when processing large datasets.
- * Uses requestAnimationFrame when available (browser), falls back to setTimeout.
+ * Uses the best available yielding mechanism:
+ * 1. scheduler.yield() - Modern browsers (Chrome 115+), specifically designed for this
+ * 2. setTimeout(0) - Fallback, allows pending events and renders to process
+ *
+ * Note: We don't use requestAnimationFrame because it only fires once per frame
+ * (~16ms at 60fps), which is too slow for data processing yielding.
  *
  * Usage:
  * ```ts
@@ -13,19 +18,15 @@
  * ```
  */
 export function yieldToEventLoop(): Promise<void> {
-	return new Promise((resolve) => {
-		if (typeof requestAnimationFrame !== 'undefined') {
-			// Browser environment - yield before next frame
-			requestAnimationFrame(() => resolve());
-		} else {
-			// Node.js or environments without rAF - use setImmediate or setTimeout
-			if (typeof setImmediate !== 'undefined') {
-				setImmediate(resolve);
-			} else {
-				setTimeout(resolve, 0);
-			}
-		}
-	});
+	// Use scheduler.yield() if available (modern browsers)
+	// This is the best option for yielding during data processing
+	if (typeof scheduler !== 'undefined' && typeof scheduler.yield === 'function') {
+		return scheduler.yield();
+	}
+
+	// Fallback: setTimeout(0) allows the browser to process events and renders
+	// This is better than setImmediate (Node.js only) or requestAnimationFrame (too slow)
+	return new Promise((resolve) => setTimeout(resolve, 0));
 }
 
 /**
