With a directory of around 1200 images, most of which are 500K jpg's, on a laptop hard drive, thumbnail update time is dominated by the time to read the existing thumbnails, rather than by generating the new ones (especially when I only add 10 or 20 at a time.) Ideally, the updater would avoid this (possibly by comparing timestamps of the real file and .xvpics file?) but alternatively, a non-interactive "update all thumbnails" command that I could run at upload time (rather than at viewing time) would be very helpful...
"Mark W. Eichin" <eichin@thok.org> wrote: I don't think I'll be adding that to xzgv. The way xzgv works just isn't suited to it, and it doesn't make much sense as a viewer feature anyway. ftp://ftp.ibiblio.org/pub/Linux/apps/graphics/misc/makexvpics-1.0.1.tar.gz It's slow, but it *does* do updates.
Mark: Do you want me to close this report or mark it wontfix? In any event, I'll package up makexvpics in case anyone (else) might find it useful. Chris
Ah, yeah, makexvpics handles the offline update. Thanks. I'm still curious about why M-u takes over 30 seconds to update a directory of 1340 jpg's (810M total), even though it doesn't end up changing any of them, and xzgv already has the thumbnails loaded... but if that's reasonable, ok, go ahead and close it.
No clue on that one... I could go and take a stare at the code for a while, but I think Russell might do better seeing as he wrote it. Chris
Mark Eichin <eichin@thok.org> wrote: It has to check for subdirectories (`u' will be faster if you're only updating a single directory, especially a large one), and stat() 2680 files. This takes a while. (That said, it takes about 5 seconds here for a dir with well over 2000 JPEGs. Is your dir mounted via NFS, or something?) BTW, makexvpics is vastly slower than xzgv. I keep meaning to rewrite it in Perl or something (which would help a *lot*), but never seem to get around to it. Ah, but they could have changed since. Isn't it lovely having a multitasking, multiuser system? :-) And the only way you could reliably check for updated files/thumbnails is to... stat() them all. So, no great savings to be had there. (Also, there's no guarantee xzgv actually *has* loaded all the thumbnails anyway, given the way it loads them as an idle task. And using Alt-u guarantees that it'll have hardly any loaded, IIRC.) I'm not aware of any way to make it faster without breaking it.
No, local ext2fs on a laptop. And no, merely stat'ing all of them can't possibly take that long, when ls -l takes under a second [and does exactly the same thing: readdir the directory, and stat everything in it.] The images are jpegs, from a Canon S100 camera; nothing wierd about viewing them. Umm, how about "I hit page-down until I got to the end of the directory list and saw images for each page"? That should be at least reasonably convincing... At this point I'm half-tempted to gprof the whole thing and see what's going on... or at least start with strace/ltrace...
Mark Eichin <eichin@thok.org> wrote: Curious. You mention it being on a laptop - is your processor running at full speed? Could there be any other power-saving going on? Ok. But to be honest, this isn't really relevant. xzgv doesn't keep the thumbnail files' contents in memory, just the pixmap (and even that's actually in the X server). So even if you were prepared to assume that the thumbnails hadn't changed since this initial loading, it wouldn't help. That might be a good idea, I have to say I'm stumped. I've never seen that sort of behaviour before.