Re: Optimizing

Hi again,

I did not find my "gut feeling" mail, so I restate some of this to be sure it 
is in the discussion.

> I would have expected the extractor to not just deal with one image
> at a time...

Yes. This would be good. 

> Why not alter it to take any number of images as command line
> parameters, or no parameter to read an image from stdin (and in that
> case pipe the result to stdout)?

I think this is not good, as we want to monitor progress. KDE - for example - 
monitors the output of gift-add-collection.pl in order to drive a progress 
bar when indexing. The "pipe in file names and destinations, receive feedback 
via pipe out"-approach would fit in better with that.

> If gift-extract-features would take any number of images parameters
> on the command line, the perl hack could send it batches of N images
> to deal with.

Yes, if N is sufficiently small, this could be a way to do things. However, I 
think the command line would be pretty wieldy, so why not use a pipe anyways?

> This COULD give further performance improvements as well.
> After all, if memory allocation is in fact such a hog that replacing
> a call to calloc with a fixed array makes a difference, then you
> could surely save a lot more by just allocating that memory (with
> calloc) once, and just clear it (memset with zero) before handling
> each image, and realloc it whenever a larger image comes along.
> No (compile time) fixed sizes would be needed.
> (I'm assuming the thing isn't threaded, and that it doesn't leak
> memory or other resources...)

It surely will improve things. A lot.

Cheers,
Wolfgang

-- 
Dr. Wolfgang Müller
LS Medieninformatik
Universität Bamberg
Check out the SIG MM web site http://www.sigmm.org