Re: Why We Should Use the STL (fwd)


Subject: Re: Why We Should Use the STL (fwd)
From: Thomas Fletcher (thomasf@qnx.com)
Date: Tue Jun 06 2000 - 09:30:51 CDT


On Sun, 4 Jun 2000, Larry Kollar wrote:

> An interesting discussion, with good points on both sides....
>
> I'll just throw out my experience. On a G3/266, running LinuxPPC 1999,
> AbiWord isn't exactly poky but it just doesn't *feel* fast. I'm a
> fast typist, and AbiWord has had no trouble keeping up, but there's
> always this nagging feeling that it's gasping and panting behind the
> scenes....

I absolutely 100% agree. My litmus test for AbiWord has been
and always will be to compare it with typing in VI. The amount
of work that goes on behind the scenes is totally uncompareable
between a text editor and a word processor, but this user experience
is going to really be one of the things that AbiWord is judged on.
This combined with such things as loading speed, re-pagination
etc are going to be what directly affects the user experience.
I know because I had to go through during the Photon port where
I put in "quich and dirty" fixes to get things done that were
not optimal in the drawing code. That totally bit me later on
when I actually sat down to use AbiWord for a document longer
than one page. As a result I revisited the code, looked at
what was wrong (mainly crapping and drawing too much ... and
AbiWord _still_ does more work than it needs to on input as
far as I'm concerned, but I haven't had a chance to investigate
changeing that behaviour further yet.)

> It's hard to define, really. My problem is that I really don't have
> anything (under Linux) to compare with AbiWord. (Sure, there's LyX,
> but that's a completely different paradigm.) I don't have copies of
> the commercial offerings (the beauty of Linux on a PowerPC, you can
> get source for nearly everything that runs on it :-). I can reboot
> into MacOS and run Nisus Writer, but then I'd have to account for a
> completly different set of optimizations and bottlenecks so that's
> not a good comparo.

Loading kills me. I took a look at it one time (don't have
my notes with me) but if you just step through the loading
procedure there is one function that you can see goes away
for a couple of seconds before returning. Things like this
should be examined more closely.

> In the end, I can sympathize with the Sourcegear folks -- we really
> shouldn't use something that isn't a widespread standard. But I
> also want AbiWord to feel as light & fast as I know it really is.
>
> As some of the project leaders have said, "source code talks."
> So if Sam submits the patches, they don't break any platforms, and
> show a significant speed improvement, I don't see how anyone could
> honestly object.

I honestly object because I don't feel that just throwing
more code into the problem is going to help. I strongly
agree with the SourceGear guys on this that while cool
and easy to do, really what needs to be done is to profile
the code and work on fixing what is there. Personally
speaking the reason I don't want to throw templates into
the mix right now is that I think that it will only buy
us grief on other platforms (selfishly thinking QNX). Sure
it may work, but what it takes to make it work seamlessly
is questionable.

Up to this point I've been very happy with the fact that
we have not required the c++ standard library and that the
subset of C++ we use is the essentially structuring C.

And as I'm sure many of you who have worked on large software
projects know, two of the most instructive things you can
do to you code is repeatedly walk through it in the debugger
(as painstaking as that may be sometimes) and to profile
the heck out of it ... if only to learn the patterns in
the execution and use. Mike Crawford has a great story
about profiling ... since he's lurking I'll let him tell
it =;-)

My two cents as a project member.

Thomas
-------------------------------------------------------------
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf



This archive was generated by hypermail 2b25 : Tue Jun 06 2000 - 09:31:04 CDT