From 2f20f854e476e3cbb244e0a6b8148525c649b903 Mon Sep 17 00:00:00 2001
From: "google-labs-jules[bot]"
 <161369871+google-labs-jules[bot]@users.noreply.github.com>
Date: Sun, 5 Apr 2026 04:01:21 +0000
Subject: [PATCH] =?UTF-8?q?=E2=9A=A1=20Bolt:=20Use=20sliding=20window=20co?=
 =?UTF-8?q?ncurrency=20in=20memory=20scanner?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Replaced static chunking in `ProcessMemoryScanner.scanPIDs` with a sliding window approach using an iterator. This optimization maintains maximum concurrency levels continuously, eliminating the tail-latency stalls caused by waiting for the slowest task in a fixed-size chunk.

Co-authored-by: acebytes <2820910+acebytes@users.noreply.github.com>
---
 .jules/bolt.md                                |  3 ++
 .../Memory/ProcessMemoryScanner.swift         | 45 ++++++++++---------
 2 files changed, 28 insertions(+), 20 deletions(-)
 create mode 100644 .jules/bolt.md

diff --git a/.jules/bolt.md b/.jules/bolt.md
new file mode 100644
index 0000000..c137d48
--- /dev/null
+++ b/.jules/bolt.md
@@ -0,0 +1,3 @@
+## 2024-05-18 - Sliding Window Concurrency
+**Learning:** In Swift structured concurrency, when processing high-volume tasks using `withTaskGroup`, static chunking (e.g., `stride(from:to:by:)`) limits throughput due to tail latency (waiting for the slowest task in a chunk).
+**Action:** Use a sliding window approach with an iterator instead to maintain maximum concurrent execution limits continuously.
diff --git a/Sources/Cacheout/Memory/ProcessMemoryScanner.swift b/Sources/Cacheout/Memory/ProcessMemoryScanner.swift
index 3f8e728..15b5d68 100644
--- a/Sources/Cacheout/Memory/ProcessMemoryScanner.swift
+++ b/Sources/Cacheout/Memory/ProcessMemoryScanner.swift
@@ -97,30 +97,35 @@ actor ProcessMemoryScanner {
     ///
     /// Returns the collected entries and the count of EPERM failures.
     private func scanPIDs(_ pids: [pid_t]) async -> (entries: [ProcessEntryDTO], epermCount: Int) {
-        // Chunk PIDs to cap concurrency at maxConcurrency.
-        let chunks = stride(from: 0, to: pids.count, by: maxConcurrency).map {
-            Array(pids[$0..<min($0 + maxConcurrency, pids.count)])
-        }
-
+        // Use a sliding window to cap concurrency at maxConcurrency.
+        // This avoids the tail-latency of chunking where we wait for the slowest task in a chunk.
         var allEntries: [ProcessEntryDTO] = []
+        allEntries.reserveCapacity(pids.count)
         var totalEperm = 0
 
-        for chunk in chunks {
-            await withTaskGroup(of: ScanPIDResult.self) { group in
-                for pid in chunk {
-                    group.addTask { [self] in
-                        self.scanSinglePID(pid)
-                    }
+        await withTaskGroup(of: ScanPIDResult.self) { group in
+            var pidIterator = pids.makeIterator()
+
+            // Seed the group with up to maxConcurrency tasks
+            for _ in 0..<maxConcurrency {
+                if let pid = pidIterator.next() {
+                    group.addTask { [self] in self.scanSinglePID(pid) }
                 }
-                for await result in group {
-                    switch result {
-                    case .success(let entry):
-                        allEntries.append(entry)
-                    case .eperm:
-                        totalEperm += 1
-                    case .otherError:
-                        break
-                    }
+            }
+
+            // As each task finishes, add a new one until we run out of PIDs
+            for await result in group {
+                switch result {
+                case .success(let entry):
+                    allEntries.append(entry)
+                case .eperm:
+                    totalEperm += 1
+                case .otherError:
+                    break
+                }
+
+                if let nextPID = pidIterator.next() {
+                    group.addTask { [self] in self.scanSinglePID(nextPID) }
                 }
             }
         }