GNOME Bugzilla – Bug 774607
Strange memory usage
Last modified: 2017-12-13 19:21:24 UTC
Fedora 23 64-bit (XFCE). Meld installed from standard repo. Firstly meld appears to use a lot of memory. See attached screenshot of "XFCE Task Manager" and meld occupies the top 9 highest memory processes. Approximately 1GB each. Those meld processes were only doing a fairly normal directory diff with a few open files showing diffs. 1GB seems massively high for this. Secondly I had 9 meld processes in Task Manager but only 4 apps actually running in the desktop. As I close these apps, none of the processes actually disappear until I close the last meld application. Then all of them disappear in one go. This is wierd, and results in large memory usage unless you effectively only use 1 meld app at any time. Is this expected behaviour, and if so can we make it more "traditional". i.e. 1 app = 1 process with sensible memory usage per process. Otherwise I'll have to go and install WINE and WINDIFF.EXE and cry in a corner. As an aside: please, please consider backtracking on the gnome 3 UI. Meld has been gnome3-iffied and its crazy. Its really unusable now. No-one is going to use this app on a tablet and touchscreens.
Created attachment 340103 [details] screenshot of task manager
I've seen huge memory usage, but on version control, not folder diff scenario. I hope some additional info could help making the issue reason more clear. How huge is the directory tree you're comparing in terms of files count and in terms of sum of file sizes? What folder comparison preferences (in Meld->Preferences menu) were used? (time-and-size-only vs content-comparison vs content-comparison-with-text-filters)? What file types are displayed (Same-New-Modified)? According to usability "gnome3-iffication" - it seems having too broad meaning (inline non-modal "dialogs", global menu, style of popup dialogs, many other things...). From the other hand it's quite common that some simple change dis-improves usability or feature discoverability just because some usage scenario was not considered while making a change. So information about exact meld usage scenario that becomes harder after "gnome3-iffication" would be helpful!
Thanks for the fast reply. I have Shallow Comparison turned off in the Preferences (attached screenshot). I was doing a variety of Directory comparisons. I don't think the directory structures and number of files to be too large. An example one was the source code tree for RapidSVN application. This has 1,305 items, totalling 142.5 MB. File types displayed are all of them (same, new, and modified) However I do leave these Meld applications running for days, if not weeks. if they have a memory leak this could explain it. I'll raise separate tickets with precise new-UI issues, to make them clearer. I did a quick check on processes created and notice that after starting only 2 instances of Meld, that I have 9 processes in XFCE Task Manager. So far these have reasonable memory usage of approx 100MB each.
Created attachment 340127 [details] screenshot of preferences
(In reply to davidallen from comment #3) > However I do leave these Meld applications running for days, if not weeks. > if they have a memory leak this could explain it. Meld is written in Python + GTK+, so it's not memory leaks so much as references being incorrectly held. I've been looking for some of this and while I've found some refs being kept around incorrectly, I can't actually see any increased memory usage come from this (which is in itself slightly odd). I'm not sure how far I'm getting here without some kind of test case. > I did a quick check on processes created and notice that after starting only > 2 instances of Meld, that I have 9 processes in XFCE Task Manager. So far > these have reasonable memory usage of approx 100MB each. We create four instances for doing parallel diffing, but these shouldn't be growing like that. In current master we've given up on parallel diffing and use threads, so you can try that out if you like. On startup, Meld should take about 30M. This is a rough baseline for Python + GTK+ libraries. However, you should have 5 (6 for two startups) processes, not 9. That you have 9 suggests that something else is very wrong... we use the normal GTK+ application instance stuff and register the session on dbus, so this particular aspect feels like a local issue.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/meld/issues/118.