AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2006.01.25 00:22 "[Tiff] 16 bites PIXMAP to 16 bits TIFF in Delphi", by Hans-David Alkenius
2006.01.25 09:20 "[Tiff] Is TIFFWriteEncodedStrip function slow?", by michael Dorrian
2006.01.25 12:45 "Re: [Tiff] Is TIFFWriteEncodedStrip function slow?", by Frank Warmerdam
2006.01.25 15:12 "RE: [Tiff] Is TIFFWriteEncodedStrip function slow?", by
2006.01.25 23:58 "Re: [Tiff] Is TIFFWriteEncodedStrip function slow?", by Chris Cox
2006.01.27 00:20 "Re: [Tiff] 16 bites PIXMAP to 16 bits TIFF in Delphi", by Joris Van Damme

2006.01.25 15:12 "RE: [Tiff] Is TIFFWriteEncodedStrip function slow?", by

> -----Original Message-----

> From: tiff-bounces@lists.maptools.org

> [mailto:tiff-bounces@lists.maptools.org]On Behalf Of michael Dorrian

I am trying to improve performance in my program. I can write out all my image data once using TIFFWriteEncodedStrip and because i only use this once i thought it should be faster than this:

                                    for(row = 0;row < height;height++){
                                          read one line raw data
                                          using TiffWriteScanline write one line of raw data}
but i tested it and writing all bytes only once is actually slower. I thought the function call overhead alone would make the above much slower but it doesn't seem to be. Therefore i conclude that TIFFWriteEncodedStrip function must be very slow. Is this a correct assumption?. Maybe something else is

As far as I see it, in general, simple (i.e. single-threaded, etc) function call overhead is only considerable in two cases:

  1. the innermost loop of a quite-nested loop (for instance, calling a function for every pixel of a gigantic image)
  2. passing large amounts of data by value (which can cause extra constructions in OO, etc) when calling a function repeatedly

For case 1, you've already "unrolled" your loop into a line-by-line strategy, so you can forget about overhead there (it explains why your line-by-line version is faster than you might expect).

For case 2, both functions take data indirectly (by "reference", though some people use that term variably), so they should be equally unaffected.

(I'm ignoring other fringe cases, like "poor function design", but that's so broad, I'll just give an example. Suppose you make a function that needs a temporary buffer of a known size; if it allocates, uses, and frees the buffer every time it's called, you'll waste time on heap shuffling; if you declare the buffer static, you'll have better design, at least with respect to efficiency).

However...

Since TIFFWriteEncodedStrip uses a compression scheme, perhaps it is the compression that is taking the extra time. Do the output file sizes differ between your two methods?

(Readers are welcome to point out any heresies or dubious claims I've made about function overhead, or add to the list any that I've obviously missed). :-)