Background Fetching vs Manual Refresh for large monorepos

Tower utilizes an internal indexing mechanism to pre-cache commit metadata, enabling instantaneous search and filtering. In large-scale monorepos with thousands of branches or heavy LFS usage, the process of synchronizing this index can significantly impact system resources.

Enabling Background Fetching ensures the UI remains synchronized with the remote state, but can trigger sustained CPU spikes and high memory overhead during de-indexing phases. Conversely, switching to Manual Refresh limits these resource spikes but risks the UI displaying stale metadata or branch states during complex merge operations.

How does the application manage the memory baseline after a background fetch completes on repositories with over 1,000 branches? Is there a specific threshold where the overhead of continuous background indexing outweighs the performance benefits of real-time UI updates?