Xref: utzoo comp.unix.internals:815 comp.lang.c:33129
Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!uw-beaver!fluke!gtisqr!roger
From: roger@gtisqr.uucp (Roger Droz)
Newsgroups: comp.unix.internals,comp.lang.c
Subject: Can I minimize expansion swaps?
Keywords: expansion swap, malloc
Message-ID: <1990Oct24.215412.5192@gtisqr.uucp>
Date: 24 Oct 90 21:54:12 GMT
Distribution: na
Organization: Global Technology International, Inc.
Lines: 51

I have two programs that run well at work on a system V with paged
virtual memory and run poorly at home on a system 3 derived Xenix with
swapping style virtual memory.  I believe the performance difference to
be related to "expansion swaps", where Xenix must write the whole data
segment of the process to the swap device whenever the process size must
be increased by an mmu increment. (4K on my Tandy 6000.)

Both programs grind to a snail's pace when reading in files which will
be broken into chunks and stored in malloced memory.  In both cases, the
size of the file is a reasonable approximation of the total amount of
memory required.  (One of the programs is MicroEMACS, in case a specific
example is useful in answering this question.)

Possible solution:

	if ((ptr = malloc(<size of file>) != NULL)
		free(ptr);
	else
		/* error */

The intention is to warn the operating system that the program will
eventually need <size of file> bytes, then free the memory.  The
program will then allocate at least <size of file> bytes piecemeal as
the input file is parsed.

This solution won't work if free() is smart enough to shrink the
process when a block of memory adjacent to the end of the data segment
is freed.

The size of the file is a conservative estimate, so another expansion
swap may be necessary to complete the process of loading the file, but
performance is improved over doing an expansion swap every 4K.

Often too much memory will be allocated.  Some of the memory needed
may already be in the heap due to previous calls to free().  What I am
really trying to ask for is <size of file> bytes of not necessarily
contiguous memory as an approximation of the eventual requirements of
the program.  The sole purpose for doing this is to permit the system
to optimize the expansion of the process.

My thanks to any wizard who takes the time to offer advice.  Please
email your response, as our newsfeed is flakey.  Post your response, if
you think this is a question of general interest.
____________
               Roger Droz       UUCP: uw-beaver!gtisqr!roger
()       ()    Maverick MICRoSystems / Global Technology International
 (_______)     Mukilteo, WA 
  (     )      
   |   |       Disclaimer: "We're all mavericks here: 
   |   |                    Each of us has our own opinions,
   (___)                    and the company has yet different ones!"