Package: xzgv
Version: 0.7-2
priority: wishlist
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" <[email protected]> wrote:
> Subject: cmdline thumbnail update
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.
> 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...
ftp://ftp.ibiblio.org/pub/Linux/apps/graphics/misc/makexvpics-1.0.1.tar.gz
It's slow, but it *does* do updates.
-Rus.
Subject: thumbnail update from command line revisited
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 protected]> - http://www.lordsutch.com/chris/
Subject: Re: thumbnail update from command line revisited
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.
Subject: Re: thumbnail update from command line revisited
Date: Mon, 19 Nov 2001 23:17:50 -0600
On Nov 20, Mark Eichin wrote:
> 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
--
Chris Lawrence <[email protected]> - http://www.lordsutch.com/chris/
Subject: Re: thumbnail update from command line revisited
Date: 21 Nov 2001 13:58:22 +0000
Mark Eichin <[email protected]> wrote:
> 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
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
> reasonable, ok, go ahead and close it.
I'm not aware of any way to make it faster without breaking it.
-Rus.
Subject: Re: thumbnail update from command line revisited
Date: 21 Nov 2001 14:14:14 -0500
> (That said, it takes about 5 seconds here for a dir with well over
> 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...
Subject: Re: thumbnail update from command line revisited
Date: 23 Nov 2001 14:31:49 +0000
Mark Eichin <[email protected]> wrote:
> > (That said, it takes about 5 seconds here for a dir with well over
> > 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
Curious. You mention it being on a laptop - is your processor running
at full speed? Could there be any other power-saving going on?
> > (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...
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.
> 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...
That might be a good idea, I have to say I'm stumped. I've never seen
that sort of behaviour before.
-Rus.
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.