Re: Optimizing

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

_______________________________________________
help-GIFT mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-gift