Closed stefanhaller closed 1 week ago
Coverage variation | Diff coverage |
---|---|
Report missing for 5a5cd849d18779ff8f2d057a70550fa737a238fc[^1] | :white_check_mark: 75.61% |
:rocket: Don’t miss a bit, follow what’s new on Codacy.
Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more [^1]: Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct.
(Github decided to auto-close #2533, and I don't see any way to reopen it, so opening a new one here. Please see there for discussion and review.)
When pressing
>
in the commits panel to trigger loading all the remaining commits past the initial 300, memory consumption is a pretty big problem for larger repositories.The two main causes seem to be
This PR addresses only the first of these problems, by not rendering the entire view, but only the visible portion of it. Since we already re-render the visible portion of the view on every layout call, this was relatively easy to do.
Below are some measurements for our repository at work (261.985 commits):
And for the linux kernel repo (1.170.387 commits):
The measurements were taken after scrolling all the way down in the list of commits. They have to be taken with a grain of salt, as memory consumption fluctuates quite a bit in ways that I find hard to make sense of.
As you can see, there's more work to do to reduce the memory usage for the graph, but for our repo at work this PR makes it usable already, which it wasn't really before.