Memor leak on browsing directories

[Sergey "Shnatsel" Davidoff]

Files queries file information and never seems to free the space allocated for it. For example, simply opening a folder with 250,000 files in it got memory usage of Files over 800Mb and this memory was never freed.

See bug #1404588 for instructions on creating a directory with lots of files on tmpfs, which is perhaps the most convincing way to reproduce this bug.

I'm reporting this bug from that instance with 800Mb memory usage, so perhaps the attached ProcStatus and other files are relevant.

pantheon-files-daemon has a lot of memory used too - at about 250Mb.

In addition, such state makes everything in Files very slow. Even the startup process of pantheon-files while pantheon-files-daemon is in such state is very slow.

ProblemType: Bug
DistroRelease: elementary OS 0.3
Package: pantheon-files 0.1.5.1+r1680+pkg35~ubuntu0.3.1 [origin: LP-PPA-elementary-os-daily]
ProcVersionSignature: Ubuntu 3.13.0-43.72-generic 3.13.11.11
Uname: Linux 3.13.0-43-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.6
Architecture: amd64
CrashDB: pantheon_files
CurrentDesktop: Pantheon
Date: Sun Dec 21 07:30:58 2014
ExecutablePath: /usr/bin/pantheon-files
GsettingsChanges:

InstallationDate: Installed on 2014-12-10 (10 days ago)
InstallationMedia: elementary OS 0.3 "Freya" - Daily amd64 (20141209)
SourcePackage: pantheon-files
UpgradeStatus: No upgrade log present (probably fresh install)

[Jeremy Wootten (jeremywootten)]

As far as I can see, GOF file objects are added to a cache when loaded and never removed while Files is running (when files are renamed they are removed and added back). This presumably speeds up going back to a folder you already visited and closed. There should perhaps be a time limit how long unused files are kept in the cache?

[Jeremy Wootten (jeremywootten)]

Cancel that last remark, GOF FIles objects are destroyed - jut not using the "remove from cache function".
Confirmed however, that there is general memory leakage e.g. when opening a PropertiesWindow. However, duplicating tabs does not leak memory.

[Jeremy Wootten (jeremywootten)]

On further experimentation, it seems that GLib (or whatever is responsible for handling free memory) does not release free memory to the system until the program is closed? Even a very simple program that keeps creating a list of GObjects and then destroys them does not release the memory it has used - but it reuses the memory freed. So System Monitor shows a low initial memory usage which jumps to a large value when a large list of objects is created but does not fall when the list is destroyed (being sure to unref the Objects). However when the list is recreated the memory does not jump again so it has not leaked and become unusable. Files uses a number of lists and hash-tables which can become large when viewing or handling large numbers of Files. So the memory tends to stay at the largest amount needed at any point in time. I notice that the same effect can be observed in Thunar.