Gitu slow in large repos

I mainly work in a large git repo (on the order of 1 million commits), and gitu takes ~11 seconds to start on my fast M3 Max MacBook Pro. Any time the main screen needs to be shown it takes about this long to re-render it.

This is likely because of all of the info gitu is fetching by default, fetching untracked files, stashes, recent commits, etc. However 11 seconds is still slower than fetching that info manually would take with git via the command line, so there's probably some additional inefficiency somewhere.

Some of this slowness is unavoidable in a large repo, but some of it can be mitigated through optimizations or configuration options. For example, having an option to not show untracked files could speed things up. For comparison, magit lets one control which sections are inserted on the status screen, and provides a verbose mode that shows how long each section took to insert. This lets one omit especially slow or less useful sections to get a more usable experience in a large repo.

No files, tests, or entry points are named. Start by profiling startup and main-screen rendering in a repository with around one million commits, then compare the work with equivalent Git command-line operations. Done means measurable improvement for large repositories or a clearly specified configuration approach for omitting slow status sections.