Is it normal practice when writing a program to just write the whole thing out completely, then going in and putting in optimizations? Is this better practice only for smaller programs? --- my website

yeah, it''s best to optimize last. just so that you don''t optimize code to the point that you don''t know what the hell the code does. but there is a difference between optimizing, and writing clean, organized code. it''s better to understand all your code before modifying it to run fast.

a2k

I just visited your website...what''s the point? There''s no value there...at least have a picture of your dog or hamster. Geeee.

Perhaps we can find a more appropriate site for your question, which has nothing to do with game development or other serious topics other than it is software related. Maybe there should be adult checking for these sites like there is for those so-called "adult" sites? Hmmmm.....

It has been my experience that performance tuning takes experience. I labored under a lot of myths before I started doing it in earnest. I would pour over a program for months making massive changes to find it had virtually no effect. It could be viewed as a waste of time, but that is how I learned to find where the real problem was and what it took to fix it. The turning point for me was benchmarking. If you are guessing whether a change made an improvement you are just wasting your time. You are gaining no real experience and most likely making no real improvement. You learn a little, but once you start measuring what you are doing you start gaining experience at an exponential rate compared to what you gain without measurement.

If you are going to spend your time trying to optimize a program then first spend it learning to measure it. Once you learn to measure it and identify were a performance problem is then start changing it. That experience will tell you what you should do while you code your next program. You don''t have to wait until you code the entire program. You can measure it at any time and do it repeatedly throughout development. There is no problem in stopping to see if there is any performance problems. You want to keep a performance target though. As long as you are meeting that target then don''t waste your time optimizing. If you are missing that target then you want to at least know why. You then have to make a judgement call. That call is whether you have been doing something wasteful you need to correct and stop doing or is it just volume of work. If it is just the volume of work you certainly want to be sure you have to do all that work, but otherwise leave it to the end unless it is a section of code unlikely to change or it is interferring with your testing. The main issue is not when you do it, but how much time you waste optimizing something that doesn''t matter or reoptimizing the same routine as you make changes to it.

Anonymous Poster: My website is far from done; I just wanted to replace what was there before with what will be my new format. If you had read the one or two news posts I have there already, you would have found that out.

As for my question, it fits into this forum. It''s called "General and Game Programming Discussion."

---
my website

It is absolutely best to write your program and later optimize it. You do want to be worrying about using efficient data structures, algorithms, etc. while you''re first writing, but don''t worry about smaller tricks. Then once your codebase has stabilized, you can worry about optimizing. The reasons for doing this are many.
First, you don''t want to be wasting time optimizing code that is going to change anyway so you must wait for the code to be pretty much done. Otherwise, you might need to change the code you spent so much time optimizing.
Secondly, programmers are generally horrible at guessing where their code will be slow. Bottlenecks pop up in seemingly strange places (until you get very experienced). The only way to find out where to optimize well is to profile, and profiling is only productive if your program (or at least the part you''re concerned with) is fully functional.
Finally, you might just find that your program is already fast enough for your needs. If it is, there''s no point in optimizing any further and you save yourself a lot of effort. Many programmers mistakenly assume they need to optimize their program to death for no apparent reason. If your program runs plenty fast for its purpose on the intended systems, it''s done, leave it alone. Only if it''s too slow for its purpose do you need to optimize further.
So to sum up: Only optimize nearly finished, functional, and too-slow code.

Ten Steps to Rock-Solid Programming

1. Specifications
2. Test and Debug
3. Design
4. Test and Debug
5. Design some more
6. Test and Debug
7. Code
8. Test and Debug
9. optimize
0. Test and Debug

Here''s an excellent little article on C++ optimization techniques. You''ll probably pick up a thing or two from here.