Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!pa.dec.com!bacchus!mwm From: mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.programmer Subject: Re: On the subject of optimization Message-ID: Date: 10 Apr 91 15:39:45 GMT References: <2243@pdxgate.UUCP> <1991Apr10.060055.2829@netcom.COM> Sender: news@pa.dec.com (News) Organization: Missionaria Phonibalonica Lines: 38 In-Reply-To: mcmahan@netcom.COM's message of 10 Apr 91 06:00:55 GMT In article <1991Apr10.060055.2829@netcom.COM> mcmahan@netcom.COM (Dave Mc Mahan) writes: > One method of avoiding wasting time on unnecesaary optimizations is to >profile your code. Write some timer routines and throw it in with >Forbid()/Disable() or whatever works for your project. Then go look at >the slower code and see what you can do to speed it up. This is an excellent technique and should always be tried first. However, it is not the be-all/end-all when some types of optimizations are needed. Actually, it's should be the first step of _any_ optimization. Even if you KNOW what operations are taking to much time, you should stop and prove it. Your intuition is frequently wrong. There are certain operations that are just plain math or compute intensive and just plain require at least some feedback from the assembly language output of a compiler to get right. Actually, once you know that's what's going on, you should see how big a table of precomputed values would be. Don't forget that interpolating intermediate values can save you orders of magnitude on the table size. No amount of assembler tweaking will make calculating values faster than an indexed move. I guess the bottom line is: Keep it simple, but know what is going on. No - keeping it simple may not be the way to make it fast; some algorithms are inherently complex. Making a simple algorithm complex is bad, as those tend to be the assembler-tweaking type wins, not the wins you get from going to a faster algorithm. Of course, to know what is going on, you need to profile the code, and know the behavior of the algorithms involved.