Alex Purins

Workaround found - set "Retrieve last" value to something small (in Settings Options Commits). Slowness was not caused by the large number of files, but a large Revisions list. The formatted git log command in PanelRevlist.UpdateList was very fast when run separately, so slowness is in the processing of its output, which was 1.2MB with 16,935 entries (my other projects are a tenth of that size). Could not quickly see why that panel refresh code was being called on all other panel refreshes (even...

Same regardless of right tab, following appears in the Log window immediately, and any changes appear in the Status panel very quickly, then unresponsive to the 16s mark (the git log below, when run at bash command line and redirected to a file, has 16,692 lines, and takes under 2 sec, consistent with Sourcetree's timing): Exec: C:\Program Files\Git\bin\git.exe status --porcelain -uall -z git branch -a Exec: C:\Program Files\Git\bin\git.exe branch -a ...handful of branch names... Exec: C:\Program...

Looking now more closely, the 1.5GB was for the entire project directory, including 1.0GB .git repo subtree, so only 500MB to be Git-checked. And unusual because it is not just sources but also binaries (since production installs are themselves full Git repos), around 450MB (and 9500 of the files) in jarfiles, images, fonts, etc. Leaving around 50MB and 5300 conventional sourcefiles, not unreasonable. So there's probably not much else around like it.

A new project is taking 16 seconds to refresh the Status panel, where Sourcetree takes under 2 seconds, for 1.54GB in 14,843 files in 1,002 folders (while in smaller existing projects, the Status panel continues to refresh sub-second, eg for 143MB in 2,315 files in 146 folders). So there is something inefficient in how GitForce interacts with Git, or itself checks for differences ? Am using current GitForce 1.0.58, on current Windows 20H2, Lenovo T590, WDC SN720 SSD, with git version 2.23.0.windows.1....