Re: Speed is important (was Re: Why We Should Use the STL (fwd))


Subject: Re: Speed is important (was Re: Why We Should Use the STL (fwd))
From: Paul Rohr (paul@abisource.com)
Date: Mon Jun 05 2000 - 13:15:48 CDT


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 - 13:10:10 CDT