delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/11/04/10:55:58

Date: Thu, 4 Nov 1999 13:47:51 +0100
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Message-Id: <199911041247.NAA12665@acp3bf.physik.rwth-aachen.de>
To: entropic AT mpx DOT com DOT au (infinity girl)
Cc: djgpp AT delorie DOT com
Subject: Re: mcount, and gprof
Newsgroups: comp.os.msdos.djgpp
Organization: RWTH Aachen, III. physikalisches Institut B
X-Newsreader: TIN [version 1.2 PL2]
Reply-To: djgpp AT delorie DOT com

In article <38215F61 DOT 35BDEC90 AT mpx DOT com DOT au> you wrote:
> i was profiling a program today, and i would just like to know which
> library functions call 
> "mcount"?   

In a stock libc.a, none of them do. '_mcount()' is the profiling
counter function. In an .o file compiled with the '-pg' option of gcc,
_every_ function calls _mcount(), immediately when it starts (and
every time it starts).  _mcount() is the book-keeping function that
counts invocations of each function. But library functions aren't
usually compiled with profiling enabled (unless you made your own
profiling version of libc, that is), so they won't ever call
_mcount().

> also, i was wondering if there is any way of making profiled programs
> run faster...i am profiling a text compression/decompression program,
> and it usually takes 11 seconds to compress a 2MB file, but with
> profiling it took over half an hour

Profiling as is additional work for the program, so profiled programs
will always run a bit slower than their un-profiled versions. But a
factor of 180 is indeed a bit much. You should check your version of
DJGPP. Old versions (v2.00 or 2.01, I think) used to have a bug that
caused mcount to write to the monochrome screen, which takes quite an
amount of time.

Other than that, if you have terribly many calls to mcount, that means
you have terribly many calls to your own functions. That load might be
reducible by using the '-O3' optimization level, which automatically
inlines small functions, instead of calling them. Leading to less
function call overhead, and fewer calls to _mcount().

> i understand there is alot of overhead..some of my functions were called
> hundreds of thousands of times {like the function to retrieve one bit
> from a buffered bitstream}.

A mere hundred thousand calls to _mcount() don't usually take anywhere
near half an hour. In my own projects, I've seen small functions being
called 10 million times, or more, and there was no noticeable slowdown
of program execution, at all. This strengthens my suspicion you have
the buggy mcount() in your libc.

--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -


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