Author: Russell Reagan
Date: 19:16:36 06/23/04
Go up one level in this thread
On June 23, 2004 at 21:03:33, Dann Corbit wrote: >I don't think I have ever disagreed with any post more than I disagree with this >one. >;-) Yeah, yeah. It's not the first time someone has said that about something I've written :-) >My point: >1. Write clear code. >2. Choose good algorithms. >3. Write abstract code that hides the implementatiion details when possible. The advice, as it is usually given all over the internet, only consists of what you have written below. By itself it is not bad advice, but I think it is incomplete. I think it is possible for someone to obey points 4 and 5 and still have a slow program. Your advice is more complete, and if someone followed it, they could work their way out of a bad situation since the abstractions grant more flexibility. >4. When everything works well, profile it. >5. Speed up the stuff that will benefit from it. I'm not saying the advice should include, "Optimize early and often!" I'm saying it should include, "Don't ignore optimization issues." That isn't to say that you start micro-optimizing right away. Just keep those issues in mind. These guys say it better than I do. Bjarne Stroustrup: "A good design cannot ignore basic efficiency requirements." Scott Meyers: "I have a two-pronged approach to efficiency. First, when you're designing the application, you have to consider efficiency. I'm assuming that you, as the designer, are designing something you know something about. You must make some educated guesses about where you think performance bottlenecks will and will not exist. That means efficiency might appear early in the design, just because you know certain things about the application in general. I don't think it's inappropriate to keep efficiency in mind when you design. You don't want to design something that will be inherently inefficient. The first prong of my two-pronged approach, then, is to keep efficiency in mind from the beginning. Don't completely ignore efficiency up front in favor of fine tuning later. You shouldn't bend over backwards for efficiency up front. Design so things will be efficient enough most of the time. Shoot for clear, straightforward, and maintainable code, but try to avoid introducing gratuitous inefficiencies. The second prong is fine tune later with profiling. If you find some bottlenecks in the program by running it and profiling, then go back and rewrite the presumably localized parts of the code to improve efficiency. Serious efficiency problems arise when people design systems with the attitude that, "We're just going to worry about correctness first. We won't even think about efficiency until later." The results have been pretty disastrous."
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.