Date: Wed, 14 Jun 1995 10:37:55 -0400 From: kagel AT quasar DOT bloomberg DOT com To: r DOT grunwald AT cowan DOT edu DOT au Cc: djgpp AT sun DOT soe DOT clarkson DOT edu Subject: Re: Malloc without malice 2 Reply-To: kagel AT ts1 DOT bloomberg DOT com From: "Ron Grunwald" Organization: Edith Cowan University Date: Wed, 14 Jun 1995 09:40:28 GMT+800 Reply-To: r DOT grunwald AT cowan DOT edu DOT au Art S. Kagel wrote: > I have a sort program I ported to DJGPP which malloc() and free()s all > over the place and it has never failed. I have sorted files of several > hundred thousand records which translates to over 1/2 million malloc()s > and matching free()s. Doing around 1/2 million function calls to malloc(), isn't that a bit inefficient, considering the enourmous execution thread the system has to follow to allocate a single block of memory? Using the stack might be a much faster method as you only need 3 assembly language instructions for the same task. Eg. push ebp mov ebp,esp sub ebp,BLOCKSZ Regards, Ron. In general, this might be good solution, however the program uses an iterative version of the sort so a function call is made for each record. At the very least I would have to adjust the stack pointer. But, even this would cause problems as the allocations of data structures within the algorithm function would become orphaned when the function returned and overwritten by subsequent calls. I know that I need to implement a cheaper memory manager than malloc for this app, but, it flies now so the incentive is not there. Note that for files large enough to worry about it the task is broken into temp files containing, except for the last (or if dups deletion occurs), a fixed (or at least a max.) number of records. Once the first temp file is written and its memory freed, malloc is not going to the OS for memory any longer so it is pretty fast. Thanks for giving thought. -- Art S. Kagel, kagel AT ts1 DOT bloomberg DOT com Variety is the soul of pleasure. -- Aphra Behn