Creating the desktop icons needs *loads* of RAM that isn't freed afterwards.
In issue #64 (closed) Georges Basile Stavracas Neto @feaneron commented:
Some fun discoveries I've made about this sneaky leak, and other memory-related stuff:
GNOME Shell consumes ~70MB right after starting up; Jumps to ~95MB after opening the aggregate menu popup; Jumps to ~250MB after loading the icon grid (with ~90 icons); This might be a good target for future investigation;
As valgrind doesn't detect memory leaks My guess (it's only a guess) is that gnome-shell doesn't actually leak memory. Instead it fragments the memory which means that the heap consists mainly of holes of unallocated data - but at the end of the heap there is allocated memory so no memory at the end of the heap can be given back to the system. The mechanism I know that would do this is:
- gnome-shell allocates memory for loading a compressed bitmap
- gnome-shell uncompresses the bitmap (which involves allocating memory for the uncompressed bitmap)
- gnome-shell creates a thumbnail (which involves allocating memory for the thumbnail
- This process now is repeated for about 90 thumbnails => Memory usage of about 250 Megabytes. Afterwards the garbage-collector is called, which frees about 180 small non-contiguous memory regions in the middle of the heap. Which doesn't allow to free any of the system's memody => big memory fragmentation.
In this case it would be better to
- allocate two memory chunks: One big enough for the biggest compressed image and one big enough for the biggest uncompressed one
- Creating all the bitmaps re-using the two memory chunks every time
- and then calling the garbage-collector.
There will be still a big block [sized one compressed and one uncompressed image] in the middle of the heap after that that cannot be un-claimed by gnome-shell. But there won't be an individual hole in the heap for each individual image after that.
Don't know if gnome-shell really uses the approach I have described here, though.