Slowness and constant CPU/IO usage

[WildOgr]

I'm observing small but constant CPU usage from gitui and periodic IO spikes. It seems that IO depend on repository size, it is significantly higher for the larger repository. App feels sluggish (especially file staging, there is very noticeable delay) not sure it is related.

Tried to rebuild latest code from source (scoops has outdated version for some reason), same behaviour.

Environment: Windows 10, running inside latest Windows Terminal build.

Any ideas?

[extrawurst]

The regularity of the spikes looks like the polling for changes we currently use instead of file watching: #1

[WildOgr]

I'm not sure that slowness is caused by IO, maybe something else is going on. I did some research on what gitui is polling for. It seems it likes to check config files a lot, currently modified files and git index. It seems current code is not just checks for changes but it actually reading modified files and index file. In this case during IO recording I had "Status page" opened and no file selected, not doing anything at all. All of this files weren't touched or modified, but stats indicate that their content was read multiple times.

Is it expected to work this way or polling can be improved?

Top IO stats:

[extrawurst]

my expectation is that most time is spent in checking status (aka "what is changed"). this happens in the function asyncgit::sync::status::get_status.

if you build gitui using the timing feature you can run gitui -l to print logging (including function runtimes):

this will show up in the log

18:05:39 [TRACE] (3) scopetime: [scopetime/src/lib.rs:41] scopetime: 21 ms [asyncgit::sync::status::get_status] @asyncgit/src/sync/status.rs:93

you can also dive deep into profiling via the pprof feature.

[WildOgr]

You were right. Traced it down to the following issue: libgit2/libgit2#4230

[extrawurst]

yeah its a super old issue in libgit2. we should reduce this massively once we do #1 because we do not have to constantly run the slow git_status_list in the background.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[extrawurst]

closing as dup of #1

[extrawurst]

please checkout #1310

[extrawurst]

This should also work on master now (since cf9ce9d)

[0xpr03]

Note that for linux the inotify backend still requires us to add each watched file and directory manually to the pool of watched file descriptors. Thus it's not zero-cost to watch a large set of files and we have to at least initially recursively walk through all of them.

[extrawurst]

@0xpr03 That's fine. hope its still less cost than constantly polling.