g-rh@XAIT.Xerox.COM (Richard Harter) (10/11/88)
In article <4250@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <208@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >>One thing to >>keep in mind here is that in general, you are wasting your time trying >>to optimize the entire program. Most programs spend a large amount of >>their processing time in a few critical routines. >Let's remember that this behavior is true only for *unoptimized* >programs. >After you have located the critical routines and speeded them up, the >program will spend a large amount of its processing time spread over >many routines. *Now*, if you want further significant speed-ups, you >can't just find a few hot spots. All of this depends on the specific programs and systems involved. In some applications most of the work is done in a specific area. For example, if 90% of the processing is done in a hot spot and 10% done elsewhere, you don't get the kind of effect Rahul is talking about unless the hot spot can be speeded up by a factor of 10. On the other hand, many applications are written in a layered fashion. In these applications the programs can often be speeded up by decreasing the layering. Also, costs often depend on the amount of data being processed. Quite often an algorithm that is appropriate for samll amounts of data is inappropriate for large amounts of data. A good example is searching. If you want to sporadically find whether a specific item is present in a short list of items you want to use a tight linear search loop. On the other hand if you want to find many such items in a large list you want to build a fast access data structure over the list. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.