Re: gitk: avoid obscene memory consumption

From: Markus Hitter <mah@jump-ing.de>
Date: Nov 6, 2016, 10:28 UTC
Message-ID: <ff5bb36b-e30c-3998-100d-789b4b5e7249@jump-ing.de>
In-Reply-To: <20161105110845.GA4039@fergus.ozlabs.ibm.com>

Am 05.11.2016 um 12:08 schrieb Paul Mackerras:

Show 22 quoted lines

> On Fri, Nov 04, 2016 at 03:45:09PM -0700, Stefan Beller wrote:
>> On Fri, Nov 4, 2016 at 12:49 PM, Markus Hitter <mah@jump-ing.de> wrote:
>>>
>>> Hello all,
>>
>> +cc Paul Mackeras, who maintains gitk.
> 
> Thanks.
> 
>>>
>>> after Gitk brought my shabby development machine (Core2Duo, 4 GB RAM, Ubuntu 16.10, no swap to save the SSD) to its knees once more than I'm comfortable with, I decided to investigate this issue.
>>>
>>> Result of this investigation is, my Git repo has a commit with a diff of some 365'000 lines and Gitk tries to display all of them, consuming more than 1.5 GB of memory.
>>>
>>> The solution is to cut off diffs at 50'000 lines for the display. This consumes about 350 MB RAM, still a lot. These first 50'000 lines are shown, followed by a copyable message on how to view the full diff on the command line. Diffs shorter than this limit are displayed as before.
> 
> That sounds reasonable.
> 
>>
>> Bikeshedding: I'd argue to even lower the number to 5-10k lines.
> 
> I could go with 10k.

Thanks for the positive comments.

TBH, the more I think about the problem, the less I'm satisfied with the solution I provided. Including two reasons:

- The list of files affected to the right is still complete and clicking a file name further down results in nothing ... as if the file wasn't part of the diff.

- Local searches. Cutting off diffs makes them unreliable. Global searches still work, but actually viewing a search result in the skipped section is no longer possible.

So I'm watching out for better solutions. So far I can think of these:

- Storing only the actually viewed diff. It's an interactive tool, so there's no advantage in displaying the diff in 0.001 seconds over viewing it in 0.1 seconds. As far as I can see, Gitk currently stores every diff it gets a hold of forever.

- View the diff sparsely. Like rendering only the actually visible portion.

- Enhancing ctext. This reference diff has 28 million characters, so there should be a way to store this with color information in, let's say, 29 MB of memory.

Any additional ideas?

Markus

-- 
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/