> Hi, can anyone tell me why we are spending time optimizing the pulldown menu
> code for the about dialog, when this code is generally only called upon about
> 0.001 percent of the time
> in the software application?
We're more interested in the theory and academia of the situation. Not so much
interested in actually implementing anything on a real world level. That would be
just silly.
Regards,
Professor John Doe
PhD in Computer Science
University of xyz
Work on obscure optimizations when you really need them, not first. Get the code out and working elegantly first, then track down bottlenecks.
Elegant clean code is usually fast and usually takes up less memory than more complex code! So if you aim for elegant code and design, it will usually end up faster than most solutions.
It is good practice to throw all the hand coded assembly & hard to read functions into a separate unit, or avoid it all together! See the FastCode project, where they have benchmarks of several hand optimized functions.
Sometimes we use conditional defines.
i.e:
{$define Fast}
{$ifdef fast}
fastfunction();
{$else}
regularfunction();
{$endif}
However, this makes the code more bloated with noise, so it may be a better choice to offer the fast functions in a separate unit, and call on that unit when you need it
Optimization is really useful when we know that a fast function is used a lot in heavy loops over and over again. i.e. determine the bottlenecks first.
It is good practice to name optimized functions differently or put them in a separate unit, since fast optimized functions usually have bugs when they are first created. Correctness before speed. Correct elegant code is usually small, compact, and fast anyway. One might even call a fast and optimized StringReplace function "StringReplaceF" to distinguish it, and only use the F version when the program requires speed improvements inside a heavy loop or similar.
|
