attempt to fix performance issues with a cache

[david-driscoll]

Description

This is an attempt to fix some of the performance problems (see #4159). As best I can tell each time that the commits are requested from a given IBranch the git library appears to enumerate again and again.

Related Issue

#4159

Motivation and Context

1.5 minutes to compute a version is a lot! 😄

How Has This Been Tested?

Best way I was able to test, was use the current version (6.0.2) and then compare to the results after caching. The difference in performance was 1 and a half minutes on my machine to 10 seconds.

Screenshots (if appropriate):

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[arturcic]

@david-driscoll can you provide the logs before and after the change, with the timestamps? You can remove the sensitive information. Now if the fix works as you say, maybe it makes sense to use same caching approach in the other collections in that folder?

[david-driscoll]

So logging just halts, while it's calculating source. I found 2 gaps where it's sitting around, so it's concieveable that it's happening else where, just not as prevelent.

When I was debugging I did have 74 source branches, which isn't a lot of numbers, but when you're iterating at least 2 times, things add up. I will do a quick test, cause I still have a 10 second wait or so while it's working.

      DEBUG [24-09-13 9:24:47:66] Breaking
      INFO [24-09-13 9:24:47:66] Merge base of 'gitversion-test' and 'origin/***' is ''0a556d1' - Merge branch 'main' of REPO'
    INFO [24-09-13 9:24:47:66] -< End: Finding merge base between 'gitversion-test' and 'origin/***'. (Took: 6.46ms) >-
  INFO [24-09-13 9:24:47:66] -< End: Finding branches source of 'gitversion-test' (Took: 484.98ms) >-
  INFO [24-09-13 9:25:45:30] -< Begin: Finding branches source of 'feature/***' >-
    INFO [24-09-13 9:25:45:30] -< Begin: Finding merge base between 'feature/***' and 'origin/***'. >-
      INFO [24-09-13 9:25:45:33] Found merge base of ''b1f00f5' - Automatically linting code'
...
      DEBUG [24-09-13 9:25:46:87] Breaking
      INFO [24-09-13 9:25:46:87] Merge base of 'origin/***' and 'origin/feature/***' is ''0a556d1' - Merge branch 'main' of REPO'
    INFO [24-09-13 9:25:46:87] -< End: Finding merge base between 'origin/***' and 'origin/feature/***'. (Took: 17.02ms) >-
  INFO [24-09-13 9:25:46:87] -< End: Finding branches source of 'origin/***' (Took: 1,449.28ms) >-
  INFO [24-09-13 9:26:07:41] -< Begin: Finding branches source of 'feature/***' >-
  INFO [24-09-13 9:26:07:41] -< End: Finding branches source of 'feature/***' (Took: 6.37ms) >-

[david-driscoll]

I gave it a shot, and went from 14s this morning to 12s. Honestly that's within margin of error, so I can't say it really did much.

If you want I'll be glad to push the code, it doesn't break anything that I'm aware of (unit tests are running now), however I don't have any evidence it will have any real effect.

[david-driscoll]

I have discovered similar behavior with this repo as well: https://github.com/RocketSurgeonsGuild/Nuke which is public, so clone away! As long as you're on a branch other than master the calculation took 1m5s with 6.0.2 and then it was 7s with these changes.