GNOME Bugzilla – Bug 169867
memleak when viewing folders with image thumbnails
Last modified: 2007-09-25 14:19:33 UTC
1. Open a large folder with many images in nautilus 2. wait until they are all thumbnailed or the thumbnails are loaded 3. close the window When you look at the memory consumption before and after you will see a great difference. IMHO nautilus should free all thumbnails from memory when the window containing them ist closed
This may be a bit hard. The images could be getting loaded in the sbrk area, which means that fragmentation prevents stuff from being freed to the os. A solution would be to make sure the memory is mmap'd so that it can be freed. Can you try this: open and close the same folder 10 times. Does the memory usage go up?
No it remains almost the same after the next times the folder is opened. but a few milliseconds before the thumbnails got reloaded the memory usage gets down to the same level as before opening the folder the first time and then very fast up again. hope this helps
Alex, Martin, Dave - what do you think? Should we remove the cached thumbnails from memory after closing a folder?
...or rather, not cache thumbnails at all
Alex, Martin, Dave?
I can confirm this issue is a _critical_ problem. I can also verify that holding all of these thumbnails in memory is doing ZERO to make opening the direcory a second time faster. I have timed with a stopwatch opening an image directory on my system 10 times. There was never more than a few second variation, which accounted for little to no reduction in wait time (my directory takes several _minutes_ to open with nautilus on a 3.4Ghz w/ 2G of memory). Also placing the folder in "list view" is no help, as the new list/tree view loads and displays all of the thumbnails anyway. When you close the folder you really should free all of the memory/cache associated with it, espically if it isn't doing anything to speed up the process. It merely provides a handy 1.1G of allocated memory I need to clean up by loging out and loging back in... nasty stuff.
I agree with Gregory that this can be a big issue if you have huge image folders.
Has there been any progress or is there anything we can do to help (sysprof?) Is this the right place for the bug or does it need to be reassigned to another library/product? Would a possible solution be to impliment a loading mechanism similar to that used in f-spot: * Load x-number of thumbnails and refresh display (realize window) * As user scrolls down continue to load x-number of thumbnails ahead of last displayed line. * Also, as user scrolls down, release the previous thumbnails from memory, leaving at least x-number of old thumbnails in case the user scrolls up. * If the user quickly "skips" (pulls to the bottom), load all visible images for that window area and x-number for scrolling around as before.
What's the status of this bug? Are there any plans for it? BTW, the folders do not have to be huge - a 7.0M folder containing 30 SVGs and 60 PNGs caused the memory consumption of Nautilus to go from 182Mb to 1.2Gb (that is 1200Mb!!!). None of the memory was freed when closing the window.
Okay, played around with it a bit. The 60 PNGs do not cause Nautilus to change memory consumption notably. The SVGs are responsible for the 1Gb of memory leak.
Uri: Maybe you could try Nautilus 2.15.2, which should significantly reduce the memory consumed when generating image thumbnails.
Seems fixed in Nautilus 2.16.3.
Looks good to me too. Closing as fixed. - Mike