>>>>> "Greg" == Greg Troxel <g...@ir.bbn.com> writes:
Greg> "John Stoffel" <j...@stoffel.org> writes: >> I've been a long time fan of GQview and now geegie v1.0 on Debian >> Squeeze (6.04), but I've run into one issue that's driving me crazy. >> I dumped a bunch of my photos into a single directory and started >> browsing them so I could delete those which were out of focus, poorly >> composed, etc. But with 3000+ photos, deletes take 3-5 seconds each. >> With only 300-500 photos, it's much much quicker. Greg> I have seen the same issue. Oh good, I'm not the only one then... >> I've turned off safe delete to see if that was the problem, but I >> don't think it is, since it's still slow to do deletes. I assume it's >> because you're updating the thumbnail view? I can see some disk >> lights going, but I haven't had the chance to investigate in detail. Greg> I have found that clearing out ~/.gqview/trash before starting Greg> helps a lot, but that's about safe delete. >> I admit I'm also running it inside a VM with only 512mb of RAM setup, >> but that's really the only thing I'm doing inside that VM is >> manipulating my photos. The VM is hosted on a Debian box with 8gb of >> RAM and a Quad AMD Phenom II X4 945 processor. >> >> Is there any debug information I can provide? I'm tempted to build a >> copy with debugging info and try to profile to see where the slowdown >> is. Is this just a limitation of the gtk2 library? Greg> I would add some kind of log statements with gettimeofday to Greg> microseconds, and sprinkle them to narrow down where the time is Greg> going. Greg> My theory is that there is some linear scan which needn't happen Greg> (on delete), and it's highly likely this is a geeqie bug rather Greg> than gtk2. Well, I went to installed valgrind and kcachegrind and grabbed some data. It's hard to interpret, but it looks like it's the sidecar files which causes the slowdown. I suspect it's because when you delete a file, it then goes back and re-sorts the entire list again, and if you have sidecars defined, it's just horribly slow. So as a work around, I just turned off sidecar files in the preferences->files tab, and nuked what was there. Made a huge difference. So hopefully someone with more knowledge of the code than I can go in and fix this. I suspect that when you delete a file, there's simply no need to re-sort the list at all. I can see how you'd want to re-sort if you did a re-name... but even then I think you can improve things. I'd love to come up with a test case using just the functions for sorting, but I honestly don't have the time to learn Gtk+ programming. Or the interest. Maybe someone else can make things work better based on this info. And thanks to all the developers, geeqie is really the best image viewer out there and I've tried a bunch. Cheers, John ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
