Subject: Re: Speed is important (was Re: Why We Should Use the STL (fwd))
From: Shaw Terwilliger (sterwill@abisource.com)
Date: Sun Jun 04 2000 - 23:53:16 CDT
Aaron Lehmann wrote:
> As a computer user, one of the most important things to me is fast,
> responsive software. I want software that I don't have to wait fractions
> of seconds on. Optimization is good - it saves CPU time and makes people
> more productive rather than waiting on their software. AbiWord may not
> have major speed problems but it sure has its share. Redraw in particular
> takes a long time on UNIX. What I would like to see most in AbiWord, as a
> second priority to fixing major bugs and implementing features like tables
> is SPEEEEEDDDDD! You can probably see how this fits into the discussion,
> because switching to STL would be mostly for performance reasons.
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.
When we added features to AbiWord (rulers, margins, text, images, etc.) we
did so with the following things in mind, and in roughly this order of
importance: correctness, completeness, efficiency, and speed.
"Correctness" is the property of a feature to do the right thing all of the
time, and under all circumstances. Admittedly, things called "bugs" often
hinder our progress towards this goal. To be correct, each feature must
have goals. Traditionally features were modeled after existing, familiar
implementations in programs like Microsoft Word or WordPerfect.
"Completeness" means implementing all parts of a feature being moving on
to the next. For a variety of reasons, many AbiWord features aren't completely
implemented. However, we've always realized that complete implementation of
all features is a 1.0 release requirement. Users expect a slidey ruler
widget to respond to mouse clicks, drags, and releases over every visible
pixel of it, and incomplete features are marks of annoying software.
I differentiate between "efficiency" and "speed" in a way that maybe only I
perceive. Efficiency is a general "correctness" of an algorithm or
implementation that leaves room for further optimization (for speed, size,
scalability, etc.). This efficiency is a measure of the amount of
time needed for a developer to get back into "maintenance" mode for a feature
in the future. Speed is "functional distance" covered in "user time".
Hopefully, if we've made our implementations "efficient", making them
"speedy" will be easy. I'd start with a profiling of the font rendering
code path. We have some dynamic memory allocation going on during character
width measurement. A long time ago, I made a pass at using a static
memory buffer for measuring these widths, but didn't have time to
determine an optimal size for these buffers. The obvious natural size
for these areas of memory would be large enough to hold widths for
the largest average runs of text in a document. This size, of course, varies
by font size, paper size, document formatting, and other document properties.
We might also spend time looking at our GDK calls to make sure we're doing
other drawing and measurement things in sensible ways, but I think our
biggest wins will be in the area of drawing text.
-- Shaw Terwilliger
This archive was generated by hypermail 2b25 : Sun Jun 04 2000 - 23:53:17 CDT