Subject: Re: Speed is important (was Re: Why We Should Use the STL (fwd))
From: Aaron Lehmann (aaronl@vitelus.com)
Date: Mon Jun 05 2000 - 16:17:45 CDT
Thanks, I think it would make sense to do a thorough profiling before
starting to optimize. Can anyone recomend a good UNIX profiler so I can
get to work on this? I've heard of gprof but never really used it.
Aaron Lehmann
On Mon, 5 Jun 2000, Paul Rohr wrote:
> At 11:53 PM 6/4/00 -0500, Shaw Terwilliger wrote:
> >Admittedly I've been out of the main development loop for the last few
> >months, but I feel the need to address the issue of speed-optimization in
> >AbiWord. To my knowledge, no attempt has been made to improve,
> >in large part, the drawing speed at the Unix screen GC level. I'd also
> >like to take time to admit that it does seem less efficient than the
> >Windows implementation, and I would love to see it gain some speed.
>
> Aaron,
>
> Shaw makes an excellent point here, which I'd like to underscore -- if
> there's a portion of the app which doesn't feel zippy enough, then profile
> it to find out EXACTLY why. Making random changes which "ought" to speed
> things up is not the way to proceed.
>
> For example, we've known since the piece table was originally implemented
> that it does uncached linear searches for certain operations. This is very
> reliable -- by contrast, caches are notoriously brittle -- but not
> theoretically optimal. Yet to date there's been no reason to change this
> behavior. Why?
>
> Well, the last time Jeff and I profiled the app, we were trying to figure
> out why certain screw cases took way too long to import. (This was almost a
> year and a half ago.) The fix above sounded plausible, but when we ran the
> profiler, we learned that the performance bottleneck was actually someplace
> else and was a nearly trivial fix.
>
> Since you're interested in improving the speed of the Unix drawing code, by
> all means feel to crack out your profiler to figure out exactly why it's
> unacceptably slow. Shaw gives some excellent theories in his message, but
> the only way to find out for sure is to crack out the profiler and do some
> experiments:
>
> Step 1 -- profile the speed of the current algorithm
> Step 2 -- figure out where you're spending the most time
> Step 3 -- make a change which ought to speed up that code
> Step 4 -- profile it *again* to see whether you were right
> Step 5 -- repeat
>
> I can't stress enough how important it is to compare the results of steps 1
> and 4. Just making a change in isolation (a la step 3) is definitely not
> the way to proceed.
>
> Paul,
> junior scientist
>
>
This archive was generated by hypermail 2b25 : Mon Jun 05 2000 - 16:17:48 CDT