Is there a performance difference between “if ‘expresion’ AND
and “if ‘expresion’ if ‘expresion’ “ you know, nested V.S logical
Please log in or register to post a reply.
Probably not. In fact, because of
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).
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?.
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
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 (:
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.
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.
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.