X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f Date: Mon, 11 Feb 2002 13:48:38 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: djgpp AT delorie DOT com Subject: Re: Alignment problem In-Reply-To: <3C679916.8915C74F@yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 11 Feb 2002, CBFalconer wrote: > gcc 2.953. I'm not sure -a is supported. In fact, I'm not sure -a is supported in _any_ DJGPP port of any GCC version. > Lots of time, see below. At least until I can get a > detailed look inside free. Well, I'm not sure: the 1.17 second taken by `free' is only about 20 clock ticks, so you are still pretty much on the clock granularity level. > I suspect free is talking back to the dpmi memory manager. You have the source, and it should show that `free' doesn't issue any system calls (because DJGPP programs never release any memory to the DPMI server). So I think the calls to __dpmi_int are irrelevant to what `free' does, it's just that your program calls some system services elsewhere, and the profiling code catches some of these calls when it randomly probes the EIP at each clock tick. I think if the main loop of your program, the one that allocates and frees objects, runs longer, the percent of time spent inside __dpmi_int will go down (assuming it's more-or-less constant overhead during program initialization and shut-down). `free' calls 2 subroutines (`merge' and `b2bucket'), but they are both inlined. I'd suggest to edit malloc.c, delete "inline" from these two functions' declarations, and then rebuild and rerun the test program again. Perhaps that will show that one of them takes most of the time.