Skip to content

Conversation

@DannyStoll1
Copy link

This PR fixes/closes #2823

It changes the following:

  • Remove tick from StatusParams hash
  • Add generation counter that increments after each fetch completes
  • Include generation in cache hash

This ensures:

  • No repeated fetches while one is already pending, making gitui usable in very large repos
  • New fetch starts immediately after completion, keeping gitui responsive in small repos
  • External file changes will still be detected on the next fetch cycle

I followed the checklist:

  • No added unittests: the change is a behavioral fix to existing code, and the existing tests pass
  • I ran make check without errors
  • I tested the overall application: on my 1.7M file target repository, load time goes from 5+ minutes to ~2.5 seconds
  • I added an appropriate item to the changelog

Replace time-based cache invalidation with a generation counter.

The old `StatusParams` included a millisecond timestamp (tick) in its
hash, causing the cache to invalidate on every UI tick. For large repos
with millions of files, this led to repeated index loading and 5+ minute load times.

This change uses a different strategy to manage cache invalidation:
- Remove tick from StatusParams hash
- Add generation counter that increments after each fetch completes
- Include generation in cache hash

This ensures:
- No repeated fetches while one is already pending, making gitui usable
  in large repos
- New fetch starts immediately after completion, keeping gitui responsive
  in small repos
- External file changes will still be detected on the next fetch cycle
@extrawurst
Copy link
Collaborator

Oh wow interesting, I wonder when we broke that. Great find

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

gitui extremely slow on large repositories

2 participants