Am 05.11.2016 um 12:08 schrieb Paul Mackerras: > On Fri, Nov 04, 2016 at 03:45:09PM -0700, Stefan Beller wrote: >> On Fri, Nov 4, 2016 at 12:49 PM, Markus Hitter <m...@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/
