> Martín Ferrari wrote: > >> llgal runs identify in each image in each run, just to verify that these >> are, in fact, images. This wastes a lot of resources, as identify is >> very slow, and can take ages on big directories. Most surely this can be >> better done with file, but for the time being, I'm just skipping the >> check (as is currently done with movies). >>
I did some testing on a directory containing 1000 jpeg images. I am only timing the "listing entries" part since this is where identify is called. The next part might be much longer because it generates thumbnails and scaled images (but it is generally only done once, not when regenerating a new gallery). 1) with a regular llgal 0.13.12, it takes: real 1m41.503s user 1m15.733s sys 0m11.617s 2) with your patch to skip identify without detecting broken images anymore: real 0m0.520s user 0m0.148s sys 0m0.032s 3) when using 'file' instead of 'identify' (and without writing the code to parse the output of file, which is not trivial since I support multiple image types): real 0m22.979s user 0m13.057s sys 0m2.304s 4) with the ExifTool perl library to get image dimensions (seems to detect broken images well): real 0m17.868s user 0m12.953s sys 0m0.200s 5) with the Image::Infos perl library (seems to detect broken images well too): real 0m1.444s user 0m0.672s sys 0m0.560s (4) is already a very nice improvement and has the advantage of being very easy to integrate in the current code. But the best seems to be (5) and it should be easy to integrate too. However, there's only a 16s difference between them, which means about 1 second for 60 images. If ExifTool brings other interesting advantages, it might be worse using it anyway even if it is a little bit slower. I'll look at all this more deeply and release a new llgal in the near future. Anyway, I'll try to run such a test before new releases in the future, I didn't expect such a timing difference (even if running llgal on 1000 images is probably not so common :) Brice
