@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).

@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

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.

@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

Quality Gate Passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

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

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

main: peak around 380MB
image

this pr: peak around 725MB
image

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

main: peak around 380MB image

this pr: peak around 725MB image

btw what are you using for the memory usage analysis?

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:
image

pr:
image

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: image

pr: image

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

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.

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:
image

pr:
image