Received: by whizzer.wpd.sgi.com (/911001.SGI)
	 id AA29215; Mon, 29 Nov 93 22:07:56 GMT
Received: from sgi.sgi.com by whizzer.wpd.sgi.com via SMTP (/911001.SGI)
	for /usr/people/sam/majordomo/wrapper resend -l tiff -h sgi.sgi.com -f tiff-owner -s -m "-oi -odq -om" tiff-list id AA29203; Mon, 29 Nov 93 14:07:46 -0800
Received: from ernie.zis.ziff.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI)
	for tiff-relay@whizzer.wpd.sgi.com id AA28490; Mon, 29 Nov 93 14:07:43 -0800
Received: from epub.ziff.com by epub.ziff.com (PMDF V4.2-13 #3828) id
 <01H5W8GO2GK096VLK6@epub.ziff.com>; Mon, 29 Nov 1993 17:07:38 EST
Date: Mon, 29 Nov 1993 17:02:56 -0500 (EST)
From: Craig Jackson <CRAIGJ@epub.ziff.com>
Subject: Speedup of G4 FAX decoding?
To: tiff@sgi.sgi.com
Cc: Craig Jackson <CRAIGJ@epub.ziff.com>
Message-Id: <01H5W8O0QIS496VLK6@epub.ziff.com>
Organization: Ziff Information Services, Medford, MA
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Sender: tiff-owner@sgi.sgi.com

My profiling of G4 FAX decoding with 3.3beta2 seems to point a finger
at subroutine call overhead as a significant factor using VAX C on VMS.
In particular, the finddiff routine in tif_fax3.c, which is a wrapper for
the findspan routine in the same file, shows up a lot in the profiling.

Has anybody considered replacing finddiff with an equivalent macro?

Tried it and found any benefit?

I know that VAX C and VMS have a heavy calling overhead by today's standards,
but would this be a generally interesting change?

Craig Jackson
craigj@epub.ziff.com
Electronic Publishing,
Ziff Information Services


