06-26-04 03:11 PM
sean larsson wrote:
> On 22 Jun 2004 17:56:11 -0700
> pembed2003@yahoo.com (pembed2003) wrote:
>
>
>
>
> man gprof. and if u google for profilers you'll find other stuff. those tools wil
l tell you what functions are taking up time, but if you want to get specific as to
what loops are doing what, u need something else. there is a tool that intel provid
es
for intels only obviously. it is pretty in depth, but not free. i wrote a tool for doing this, it work
s on pentiums and uses the rdtsc instruction. see here: [url]http://forums.devshed.com/t108319/s.html[
/url]
>
As a first step "gprof" is pretty good in that it tell you what
routines are being called most often and take up the most
time. At least you can narrow it down that way.
Example: 98% of the time is being spent in routine foobar().
Choices:
1. Call foobar() less often
2. Find a replacement for foobar()
3. Optimize foobar()
Choice 1 is almost always better than choice 2, in my
experience, but it's harder to do, so most folks
start right on choice 3. In a previous thread, one
poster, whose name I forgot, mentioned that he saw
someone once try to optimize the assembler for
a bubble-sort routine.
Look at both the frequency with which a routine is
called *and* the percent of total time that
the routine takes up. If all you have is one
big routine, maybe you should re-evaluate your
design decisions.
Past that, it's up to you to know how to do things
as move invariants out of loop constructs and such.
If "gprof" shows that the usage is evenly spread out
between 20 or so routines/functions/methods, you are
usually SOL.
NPL
--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
[ Post a follow-up to this message ]
| 
