AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

1997.03.11 06:09 "Win32 Optimizations !!!", by Shabd
1997.03.12 06:05 "Re: Win32 Optimizations !!!", by Rainer Wiesenfarth
1997.03.12 09:15 "Re: Win32 Optimizations !!!", by Karsten Spang
1997.03.12 11:17 "RE: Win32 Optimizations !!!", by Pesce Roberto
1997.03.12 22:45 "RE: Win32 Optimizations !!!", by Bill Elswick
1997.03.13 13:42 "RE: Win32 Optimizations !!!", by Scott Wagner
1997.03.12 13:44 "Re: Win32 Optimizations !!!", by Scott Wagner

1997.03.12 13:44 "Re: Win32 Optimizations !!!", by Scott Wagner

Hello Shabd,

  1. Replace malloc family of functions with HeapAlloc family.

In applications which do not do repetitive dynamic memory allocation/deallocation (this is the case with LibTiff) I have not seen significant benefit from use of HeapAlloc over GlobalAlloc / LocalAlloc. Win32 seems pretty good at establishing paging tables so that access to these memory objects is efficient with either method. Have you had different results?

The HeapAlloc family might help with the peculiarity noted in the following comment extracted from tif_win32.c:

/* Memory allocation is handled in one of three ways, primarily because of a
problem with the Win32 API GlobalReAlloc() call. The default behavior is to
use the compiler's ANSI malloc() family calls. If WIN32_ALLOC is defined,
the WIN32 API functions are used, but GlobalReAlloc() is avoided by use of a
GlobalAlloc(new) - CopyMemory(old->new) - GlobalFree(old) sequence. If
OLD_WIN32_REALLOC is defined (for backward compatibility), the
GlobalReAlloc() API is attempted. THIS CAUSES MEMORY EXCEPTIONS IN SOME
CASES, AND IS NOT RECOMMENDED! */

  1. Replace fwrite family of functions with ReadFile family.

fwrite is not used in tif_win32.c. _tiffWriteProc and _tiffReadProc point to WriteFile and ReadFile API functions. Am I missing something here?

Regards,

Scott Wagner (wagner@itek.com)
Staff Engineer
Itek Graphix
Rochester, NY USA