Improve Submodule Status performance

[gerhardol]

Do you want to request a feature or report a bug?
"feature"

What is the current behavior?
Obtaining the submodule status may require a lot of resources, as in #5733.
It is possible to deactivate the status (#5756), a few very minor improvements too (#5747 and #5742).
The performance can be improved, some discussions in the issues/PRs. This is a proposal on the way forward.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.

What is the expected behavior?

Some possible improvements, listed in some kind of order:

• only update submodule status at changes #5777 Only update submodule status when there are changes (when commit-count indicate submodule status)
• use --no-optional-locks for submodule status and stash list #5983 Run the submodule diff with --no-optional-locks (set a 'background' attribute to GitModule?)
• Trigger submodule status update from commit-count only. (Limited effect before splitting the structure/status.) This can be done on commit-count only, removing the delay in Browse: Delay status updates when opening/refreshing repos #5747.
• Separate submodule structure and status #6445 Separate obtaining structure (that should be done soon after switching repo and refresh only, maybe at submodule form too but ignore external changes). This will give a quick setup of the structure used in the menu (and later in Feature: add a Submodules tree to the left panel #5617) without requiring the status to be obtained directly.
• Separate submodule structure and status #6445 Only calculate the status for submodules that are dirty/changed, known from the commit-count status (this really requires Git 2.15 or something). This should prune the number of commands considerably - the normal use case with submodules are to update few of the submodules.
  - [ ] WIP Optimize create copy of GitModule() #6373 Optimize creation of GitModule, much data can be copied when creating GitModule for super/submodules. (At least git ref-parse --git-common-dir is required, the about 50 ms increases to over 300 ms with simultaneous invocations).

See also #6372, improved the overall responsiveness

Environment you encounter the issue:

• GitExtensions version: master

Did this work in previous version of GitExtensions (which)?
2.x with status worked slightly better than 3.x with status, 3.x much snappier without status.

[RussKie]

Can any of the items be ticked off?

[gerhardol]

#6445 is still open (after the structure change the missing tests were easily spotted, however they are failing now).

[gerhardol]

Closed by #6445