Only the treemap is limited to 4 levels. The whole file system needs to be scanned to know how much space is used. The treeview is also populated with all the data which most likely is the reason for the memory usage. I'll see if it could be filled dynamically so that only the visible branches would be kept in memory.

It's still opening files considerably deeper than 4 levels - excerpt from strace - 2253 02:05:53 stat64("/home/user/data/backuplap/home/user/.gqview/thumbnails/mnt/data/photos/hda6image/photos/allphotos/mntc/laptopbackup/mnt/photos/cf/dcim/576canon/img_7670.jpg.sim", {st_mode=S_IFREG|0644, st_size=65, ...}) = 0 2253 02:05:53 stat64("/home/user/data/backuplap/home/user/.gqview/thumbnails/mnt/data/photos/hda6image/photos/allphotos/mntc/laptopbackup/mnt/photos/cf/dcim/576canon/img_7671.jpg.sim", {st_mode=S_IFREG|0644, st_size=65, ...}) = 0 2253 02:05:53 stat64("/home/user/data/backuplap/home/user/.gqview/thumbnails/mnt/data/photos/hda6image/photos/allphotos/mntc/laptopbackup/mnt/photos/cf/dcim/576canon/img_7672.jpg.sim", {st_mode=S_IFREG|0644, st_size=65, ...}) = 0

(/home/user/data/ is the filesystem being scanned.)

One way about the extreme memory use - it was using ~120M after indexing 350000 files - would be to simply count as 'small' files any files that total under a pixel of the currently found files.

This is a particularly edge-case - but it can repeatably lock up my device when it's used as directed - so thumbs down. :(