Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!uwvax!oddjob!tank!uxc!uxc.cso.uiuc.edu!uxg.cso.uiuc.edu!uxe.cso.uiuc.edu!mcdonald
From: mcdonald@uxe.cso.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: Array indexing vs. pointers...
Message-ID: <225800079@uxe.cso.uiuc.edu>
Date: 9 Oct 88 14:31:00 GMT
Lines: 24
Nf-ID: #R:<8809191521.AA17824@ucbvax.Berke:-40:uxe.cso.uiuc.edu:225800079:000:1292
Nf-From: uxe.cso.uiuc.edu!mcdonald    Oct  9 09:31:00 1988


>In article <225800077@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu gives
>six good, fairly detailed tips for optimizing C programs.  One thing to
>keep in mind here is that in general, you are wasting your time trying
>to optimize the entire program.  Most programs spend a large amount of
>their processing time in a few critical routines.

>The way to conquer this problem, and not waste a lot of valuable time
>optimizing the current program, when you could be adding features to the
>next version :-), is to profile your code.  Find out which routines the
>program spend most of it's time in, and then optimize THOSE routines.

Agreed, sometimes. Sometimes it is blatently obvious from the problem
description. Of three projects I just finished, all maybe 3000 to 5000
lines, one  does most of its work in 40 lines. One spreads out over
about 25% of the code. These were obvious from the start (pre-known
loop counts). One, my hack of Nelson Beebe's dvi driver, I couldn't
tell de novo since I didn't write it. I found a very nice profiler
called Inside! ( for the IBM-pc) on Bix. It is a crippled demo version,
but got the job done. I found that the work being done is distributed
very evenly over about 85% of the code. That means nothing can be done 
easily. Oh well!

Doug McDonald