Subject: thumbnail update from command line revisited

From: Chris Lawrence <[email-masked]>
Date: Mon, 19 Nov 2001 20:00:11 -0600

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
-- 
Chris Lawrence <[email-masked]> - http://www.lordsutch.com/chris/

---

From: Mark Eichin <[email-masked]>
Date: 20 Nov 2001 00:05:29 -0500

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.

---

From: Chris Lawrence <[email-masked]>
Date: Mon, 19 Nov 2001 23:17:50 -0600

> 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

---

From: Russell Marks <[email-masked]>
Date: 21 Nov 2001 13:58:22 +0000

> 1340 jpg's (810M total), even though it doesn't end up changing any of

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.

> them, and xzgv already has the thumbnails loaded...

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.)

>                                                     but if that's

I'm not aware of any way to make it faster without breaking it.

-Rus.

---

From: Mark Eichin <[email-masked]>
Date: 21 Nov 2001 14:14:14 -0500

> 2000 JPEGs. Is your dir mounted via NFS, or something?)

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.

> (Also, there's no guarantee xzgv actually *has* loaded all the

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...

---

From: Russell Marks <[email-masked]>
Date: 23 Nov 2001 14:31:49 +0000

> can't possibly take that long, when ls -l takes under a second [and

Curious. You mention it being on a laptop - is your processor running
at full speed? Could there be any other power-saving going on?

> directory list and saw images for each page"?  That should be at least

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.

> going on... or at least start with strace/ltrace...

That might be a good idea, I have to say I'm stumped. I've never seen
that sort of behaviour before.

-Rus.