Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!samsung!xylogics!transfer!lectroid!jjmhome!smds!rh
From: rh@smds.UUCP (Richard Harter)
Newsgroups: comp.software-eng
Subject: Re: recap so far
Summary: Many sources of software inefficiency
Message-ID: <114@smds.UUCP>
Date: 11 Jul 90 04:00:24 GMT
References: <4235@<268462df> <39400111@m.cs.uiuc.edu>
Organization: SMDS Inc., Concord, MA
Lines: 61

In article <39400111@m.cs.uiuc.edu>, johnson@m.cs.uiuc.edu writes:


> To generalize, arguments against software reuse because it will result
> in systems that are too slow are wrong.  Only the bottlenecks need to
> be optimized.  I save a lot of time reusing components and am happy to
> spend some of it rewriting working code to make it faster.

There is much to this statement, but there are also some major
qualifications.  First of all, as we all know (or do we?) the single
most likely reason for slowness is the choice of the wrong algorithm
in the wrong place.  This is a major topic in its own right.  The "right"
alogorithm quite often not the one with the asymptotic behaviour.

Given that we have the "right" algorithms, where does slowness in software
arise and what are the possible gains?  Let us take a "typical" program
and look at optimising it.  We gather our profilers and performance
analysis tools and study the hell out of the software.  What do we
find?  The first cut shows us the bottlenecks.  In a typical program you
find that 80% of the execution time is spent in a handful of routines.
What you do then is two things: (a) you optimize the individual routines,
and (b) you reduce the number of calls to those routines.  The latter is
usually more profitable.  Let us assume that we have done our job well.
We then have an execution profile that is fairly flat.  Are we done?  No.

We now have to deal with the layering effect.  A simple, extreme example
of this is code that is run on an emulator.  We can optimize the hell out
of the code but we are not touching the major source of inefficiency,
which is the invisible layer comprising the emulator.  Ordinary programs
do not have this problem; however ordinary programs are often built in
layers.  Each layer extracts its own toll in overhead.  Moreover this
toll is not easily spotted or analyzed with ordinary profiling tools.
One can be nibbled to death by ducks as well as eaten by man-eating tigers.

> Another interesting fact is that the standard Collection classes are
> really fairly efficient, considering what they do.  The average programmer
> who would try to write a linked list routine in C is likely to write
> something that is slower, and is likely to make a mistake or two.  There
> are a few people who are really good at making programs fast.  Once you
> have a library of reusable components, you should have one of them take
> a look at it and share their skills with others.

Yes and no.  It is my observation that the quality of publicly available
(standard) code is not all that it could be, although it is quite often
better than that of "the average programmer".  Reusable code of any sort
is written by someone.  That someone always has constraints on the amount
of time and effort they can spend on the code.  Optimization is expensive
in terms of human hours.  It is also expensive in terms of talent.  As
Ralph remarks, there are few people who are really good at making
programs fast.

And then there is the question of "Is increased speed worth the effort
necessary to achieve it?"  It all depends.  My estimate is that the average
program of size can be speeded up by a factor of 2-10 times.  That seems
drastic (and surely worthwhile.)  However the next generation of machines
is always cheaper than the current round of optimization.
-- 
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb.  This sentence short.  This signature done.