delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/10/30/09:52:03

Date: Thu, 30 Oct 1997 16:50:19 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Demmer AT LStM DOT Ruhr-Uni-Bochum DOT De
cc: djgpp AT delorie DOT com
Subject: Re: malloc
In-Reply-To: <783CCFA70C5@brain1.lstm.ruhr-uni-bochum.de>
Message-ID: <Pine.SUN.3.91.971030164338.5063B-100000@is>
MIME-Version: 1.0

On Thu, 30 Oct 1997, Tom Demmer wrote:

> Starting at a blocksize of 
> 100, the dl version becomes comparable or even faster than the libc 
> version. Test 3 with 15000 outperforms the libc version about the 
> factor 2.

Does the break-even point occur before or after all physical memory is 
used up?  If the latter, then on more memory-abundant machines the 
results will be different.  (And 16MB is not too much by today's 
standards.)

> What would make it interesting is the possibilty to give back memory 
> to the operating system. This is not done by the BSD version of libc,

But is there something in libc's malloc which would prevent adding this 
functionality?

> and has no real effect under cwsdpmi, because it does not change the 
> amount of physical available memory.

Oh, but it *does* change the amount of *free* physical memory, right?  So 
when a child program is spawned, you don't have to wait for CWSDPMI to 
page out some of the parent, and page it in when the child exits, right?

> I don't know if this is a 
> limitiation of the DPMI specs, but really making the memory available 
> for other processes would be an advantage in a multitasking 
> environment.

It would be worthwhile, then, to run your tests in two different DOS 
boxes on Windows simultaneously, and use some memory-tracking program to 
track the Windows memory resources during the test.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019