Improves git object cache

[arturcic]

Follow up for #4681

[HHobeck]

@pvanbuijtene: Thank you for your contribution and the work you have done.

I have following remarks/suggestions:

• The classes Commit, Branch and so on are wrapper classes around the LibGit2Sharp objects. I would say the wrapper classes should not have a reference to GitRepostory. Is it an idea to extract the functionality of caching in a separate class and use this instead?
• Because of the nature of a wrapper class I would expect that the LibGit2Sharp objects are reused as well and the hash code is the same (otherwise we would have still a memory problem). Probably you can use the hash code instead of using an arbitrary string (needs to be tested).

[arturcic]

@pvanbuijtene: Thank you for your contribution and the work you have done.

I have following remarks/suggestions:

• The classes Commit, Branch and so on are wrapper classes around the LibGit2Sharp objects. I would say the wrapper classes should not have a reference to GitRepostory. Is it an idea to extract the functionality of caching in a separate class and use this instead?
• Because of the nature of a wrapper class I would expect that the LibGit2Sharp objects are reused as well and the hash code is the same (otherwise we would have still a memory problem). Probably you can use the hash code instead of using an arbitrary string (needs to be tested).

That was my idea to move the functionality from the GitCache class back into the GitRepository as I think the repository wrapper should handle the caching mechanism as it's the abstraction of the database which maintains the collections and the cache, but we can reconsider that

[pvanbuijtene]

Happy to help :)

@arturcic as I understand you will implement the suggestions, feel free to ping me in case you want to have some changes tested against a repository causing issues.

[arturcic]

@pvanbuijtene thank you, yeah, I implemented the suggestions so far in this PR, but it's a draft for now, I want to test caching the other collections as well before having this merged

[arturcic]

@pvanbuijtene do you have the time to test this PR on the big repository you have and compare?

[pvanbuijtene]

@arturcic sure, the changes seem to have introduced some additional memory usage:

main: peak around 380MB

this pr: peak around 725MB

[arturcic]

@arturcic sure, the changes seem to have introduced some additional memory usage:

main: peak around 380MB

this pr: peak around 725MB

btw what are you using for the memory usage analysis?

[pvanbuijtene]

It's the standard monitoring when running it from Rider.

Here's some more detailed information from a dotMemory snapshot taken roughly at the peak:

main:

pr:

[arturcic]

It's the standard monitoring when running it from Rider.

Here's some more detailed information from a dotMemory snapshot taken roughly at the peak:

main:

pr:

Ok I'm also using Rider, I will have to check it out as well, thanks

[pvanbuijtene]

I will also do a check with the anonymized repo to see if the object counts are similar, this way there might still be a way to verify things with that repo.

[pvanbuijtene]

Here are the results with the anonymized repo, not exactly the same but it looks quite similar. So I would assume you should be able to get similar results when comparing main vs. this pr.

main:

pr:

[Copilot]

Pull Request Overview

Copilot reviewed 12 out of 12 changed files in this pull request and generated 4 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[arturcic]

@pvanbuijtene mind to have a review as well?, please also attach the new memory consumption data you see on your big repo.

[pvanbuijtene]

With the restricted knowledge I have of this repository... looks good, ran it twice and the memory usage of the pr branch is slightly lower.

main:

pr:

[arturcic]

With the restricted knowledge I have of this repository... looks good, ran it twice and the memory usage of the pr branch is slightly lower.

main:

pr:

thanks @pvanbuijtene. I think I will merge this one then. Thanks once again for the initial work you've done.

[mergify]

Thank you @arturcic for your contribution!

[pvanbuijtene]

@arturcic can you share some insights into when this would be released, maybe as a pre-release?

We're having some issues on our build servers which should be fixed by this update :)

[arturcic]

@arturcic can you share some insights into when this would be released, maybe as a pre-release?

We're having some issues on our build servers which should be fixed by this update :)

I think I could release it today, and the other PRs could target the next release

[pvanbuijtene]

That would be great 👍

[gittools-bot]

🎉 This issue has been resolved in version 6.5.0 🎉
The release is available on:

• GitHub Release
• Chocolatey Package
• .Net Global Tool

Your GitReleaseManager bot 📦🚀