7 replies to this topic

[3DModelerMan]

Is there a performance difference between "if 'expresion' AND 'expresion'"
and "if 'expresion' if 'expresion' " you know, nested V.S logical AND.
Thanks:w00t: .

[Reedbeta]

Probably not. In fact, because of short-circuiting, both are equivalent (in most languages), so the compiler likely generates identical machine code in both cases.

However, you should know that in general it's not worth worrying about micro-optimizations like this, except for code in inner loops and the like that gets executed thousands of times in a program. If you're trying to optimize a program you get much more mileage out of architectural and algorithmic optimizations (i.e. designing the program well and using faster algorithms and data structures).

[3DModelerMan]

Ah, thanks. I use C++ for this project by the way. What about goto?, what does it do to the program that makes it bad?.

[Reedbeta]

Overuse of goto can lead to what is called "spaghetti code", meaning code that is hard to understand because it jumps around in a disorganized way. There are occasionally situations where goto is reasonable to use; however, it should be used sparingly and only when there is a substantial advantage in code readability over other kinds of code organization like loops, branches and functions.

For more information, see the original 'Goto considered harmful' article.

[JarkkoL]

In the project I'm working on have roughly 1 goto per 20,000 lines of code, so it's like poison which can be consumed in extremely small doses not to be leathal (:

[3DModelerMan]

I guess that's not as bad as many people say it is. But I'm still going to avoid using goto as much as possible.

[alphadog]

Goto is generally an indicator of a bad spot in the overall design, or, in refactoring circles, a "smell". Usually, it indicates a section of code, nowadays usually OO, that attempts to do too much and that hasn't been broken down enough. The issue is that you take a program in one state having followed one path of code, and suddenly jettison it into another path of code. Makes debugging diffcult.

But, it can find controlled use, usually in exception handling. In fact, the try/catch construct and the switch construct are basically gotos.

Read Dijkstra's letter for more...

In fact, I've read that some people believe that the issues surrounding the use of "goto" is one of the impetus for OOP.

[Nyx]

In general, it's considered good practice to avoid any low-level optimizations until you're in the final phase of development (soon to release a product). Until you reach that point, you should mostly worry about designing your algorithms to be efficient on the large scale.

For example, if you're writing a raytracer... Implementing a space partitioning system (eg: kd-trees) can augment your performance by huge factors when it comes to large models (we're talking hundreds of times faster for very large models). Your raytracer will pretty much NEED this kind of algorithmic optimization to be useful, so you should work into your design early on. You might also be able to gain performance by re-implementing some intersection tests in assembly to use SIMD instructions (eg: SSE*), however, the performance gain there will likely be much smaller (maybe you'll make your raytracer twice as fast, which is certainly appreciated). However, you probably don't want to introduce ASM code in there until you're certain those intersection tests aren't going to change. Those low-level optimizations should probably be a "final touch"... The icing on the cake.