ngf/refsview#100
Conversation
There was a problem hiding this comment.
Didn't I relatively explicitly say that it is big bullshit to read the repository from within the painting code? I have code that does it correctly, it's not complete and not yet pushed.
Contrary to the RepoMan code (which is prepared to optimise loading / unloading of repositories), this place will always require a loaded repository doing drawing.
Loading a whole repository (just the parts we need here now) involves: Reading the configuration, the user configuration, the system configuration and all files included from within there. A recent example if LG PRs showed that this might total to 30 files in a modular setup. It further involves reading all references. Since references can be packed or loose, there's no other way than to read all loose and then amend and obsolete some of them with the packed file. This not only has to physically read the files, but will also have to do lots of memory allocations - just to discard them soon afterwards. A repository may easily have 1000 references! Note that a tag is a reference, too - and each references in a remote is a reference also. So, we already get to 1000 with just 3 remotes and a repository that has release-early-release-often policy, with the 3 typical dev / maint / next branches, 47 topic branches and 200 historic release branches/tags (If release schedule is weekly, this is just 4 years).
Even if all of that is packed into one file, I would dare to say that with the avg. line length in the refs file of 60 bytes, we have to read about 60 Kb of pack file. Then has to be parsed and checked against previous read references (i.e = 2 * n memory allocs and O(n log n) runtime)...
I don't want that to be processed during a mouse move (which in fact may trigger painting or cause the model to be read for other reasons). Other reasons that come in mind: Calculating the item height request knowledge of the font, so a hit-test during mouse move could query for the font, which as we see above reads the repository and then uses a boolean value.
We're talking about the in-memory references. This code never reads from disk. Maybe you have something different in mind? |
|
What I have in mind, is that the underlying git repository will be evicted from RepoMan, 15 minutes after the repository got deactivated. See here. I would really love to reduce this timeout and make it even valid for the active repository. As for the in-memory references, if libgit2 would not refresh the in-memory references on every lookup, how would we ever learn of changes? There's no way to explicitly force a reload. See: here, here and here. The biggest problem is, that it has to reload the loose reference, but that will eventually destroy the packed one. So it has to read the packed one again, too. The latter will cause all references to be revalidated. However, we have at least one layer above that. Which can actually treat the references as purely in-memory. You may be right here. Anyway, we should still treat the RepoMan as a fragile cache that may change between events (Talking about Qt-Events) and in cases where it had not all data available. |
|
Hm ... I think I'm going to abandon this branch, too. Take it as a source of inspiration 😄. Please keep the TODO's from the description in mind -> copy them into the description of #99. |
2 participants
To complete:
I let the image speak for itself (icons not included) ⭐:
