From b9d0a0c699337ef601dfee09478b6bd516cb0b2b Mon Sep 17 00:00:00 2001
From: "google-labs-jules[bot]"
 <161369871+google-labs-jules[bot]@users.noreply.github.com>
Date: Tue, 2 Jun 2026 05:45:01 +0000
Subject: [PATCH] =?UTF-8?q?=E2=9A=A1=20Bolt:=20Optimize=20CacheoutViewMode?=
 =?UTF-8?q?l=20computed=20properties?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-authored-by: acebytes <2820910+acebytes@users.noreply.github.com>
---
 .jules/bolt.md                                      | 3 +++
 Sources/Cacheout/ViewModels/CacheoutViewModel.swift | 6 ++++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/.jules/bolt.md b/.jules/bolt.md
index b2c1128..b6e0a9b 100644
--- a/.jules/bolt.md
+++ b/.jules/bolt.md
@@ -28,3 +28,6 @@
 ## 2025-10-24 - Bulk Disk I/O Parallelization and Thread Pool Starvation
 **Learning:** Both `withTaskGroup` and `Task.detached` schedule their work on Swift's cooperative thread pool, which has only as many threads as the CPU has cores. Running synchronous blocking I/O (like `FileManager.removeItem`) directly inside such tasks ties up cooperative threads — when every thread is parked in a syscall there is nothing left to advance other Swift Concurrency work, which manifests as starvation and (with self-referential `await` chains) outright deadlock. `Task.detached` does not help here: "detached" means unstructured/independent, not "off the cooperative pool."
 **Action:** To parallelize bulk blocking I/O, combine a sliding-window `withThrowingTaskGroup` (e.g., `maxConcurrency` of 8) with a per-item handoff to a GCD queue: wrap the blocking call in `withCheckedThrowingContinuation` and dispatch it via `DispatchQueue.global(qos: .userInitiated).async { ... continuation.resume(...) }`. The cooperative-pool task only `await`s the continuation, so it never holds a thread while the syscall runs.
+## 2024-05-30 - Short-circuit evaluations on arrays
+**Learning:** Using `.isEmpty` on a filtered array forces eager evaluation of the entire filter criteria. For checking if any elements match a condition, it's heavily inefficient.
+**Action:** Use `.contains(where:)` instead of checking `.isEmpty` on a filtered array to short-circuit evaluation, stopping at the first match.
diff --git a/Sources/Cacheout/ViewModels/CacheoutViewModel.swift b/Sources/Cacheout/ViewModels/CacheoutViewModel.swift
index 27de41a..a72c97e 100644
--- a/Sources/Cacheout/ViewModels/CacheoutViewModel.swift
+++ b/Sources/Cacheout/ViewModels/CacheoutViewModel.swift
@@ -105,8 +105,9 @@ class CacheoutViewModel: ObservableObject {
         scanResults.filter { $0.isSelected }
     }
 
+    // ⚡ Bolt Optimization: Use .lazy chaining for reduce to prevent intermediate array allocation
     var selectedSize: Int64 {
-        selectedResults.reduce(0) { $0 + $1.sizeBytes }
+        scanResults.lazy.filter { $0.isSelected }.reduce(0) { $0 + $1.sizeBytes }
     }
 
     var formattedSelectedSize: String {
@@ -118,7 +119,8 @@ class CacheoutViewModel: ObservableObject {
     }
 
     var hasResults: Bool { !scanResults.isEmpty || !nodeModulesItems.isEmpty }
-    var hasSelection: Bool { !selectedResults.isEmpty || selectedNodeModulesSize > 0 }
+    // ⚡ Bolt Optimization: Use contains(where:) to short-circuit rather than filtering entire array to check emptiness
+    var hasSelection: Bool { scanResults.contains(where: { $0.isSelected }) || selectedNodeModulesSize > 0 }
 
     // MARK: - Node Modules computed properties