[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [help-GIFT] Optimizing

From: Wolfgang Müller
Subject: Re: [help-GIFT] Optimizing
Date: Tue, 12 Sep 2006 11:44:49 +0200
User-agent: KMail/1.9.1

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


Dr. Wolfgang Müller
LS Medieninformatik
Universität Bamberg
Check out the SIG MM web site

reply via email to

[Prev in Thread] Current Thread [Next in Thread]