Re: [help-GIFT] Optimizing

[Jonas Lindqvist]

Hi!

The reason i haven't jumped on your idea, is I didn't find it very unixy at all, first read through. To me, interprocess communication UNIX-style is done by chaining lots of pipes together. and what you're talking about sounded more bi-directional than the normal UNIX softwares. XML and unixy don't quite go hand-in-hand, but now that i re-read your mail, i agree that something along the described lines would certainly be better than what we have.

I agree the feature extractor should be working in lists, but I've been avoiding structural changes, so as to get something in the tree everyone can agree on.

In an ideal world, the command line arguments, and the input streams for the feature extractor, the re-sizer, and the thumb-nailer should be close to identical. 

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

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

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.

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

/Jonas

smime.p7s
Description: S/MIME cryptographic signature