The compiler does not actually ever insert or remove parentheses; it just creates a parse tree (in which no parentheses are present) corresponding to your expression, and in doing so it must respect the parentheses you wrote. If you fully parenthesise your expression then it will also be immediately clear to the human reader what that parse tree is; if you ...
"Premature optimisation" is not about using optimisations early. It is about optimising before the problem is understood, before the runtime is understood, and often making code less readable and less maintainable for dubious results.
Using "const&" instead of passing an object by value is a well-understood optimisation, with well-understood effects on ...
Theoretically yes, but practically it's rarely worth it.
Both CPUs and GPUs are turing-complete, so any algorithm which can be calculated by one can also be calculated by the other. The question is how fast and how convenient.
While the GPU excels at doing the same simple calculations on many data-points of a large dataset, the CPU is better at more ...
Asuming expensive_calc_one and expensive_calc_two are pure functions
Unfortunately, determining whether a function is pure is equivalent to solving the Halting Problem in the general case. So, you cannot have an Ahead-of-Time compiler which can in the general case decide whether a function is pure or not.
You have to help the compiler by explicitly ...
The number one thing should always and forever be readability. If it's slow but readable, I can fix it. If it's broken but readable, I can fix it. If it's unreadable, I have to ask someone else what this was even supposed to do.
It is remarkable how performant your code can be when you were only focused on being readable. So much so I generally ignore ...
The parentheses are there solely for your benefit - not the compilers. The compiler will create the correct machine code to represent your statement.
FYI, the compiler is clever enough to optimise it away entirely if it can. In your examples, this would get turned into int a = 6; at compile time.
In C# and Java implementations, the objects typically have a single pointer to its class. This is possible because they are single-inheritance languages. The class structure then contains the vtable for the single-inheritance hierarchy. But calling interface methods has all the problems of multiple inheritance as well. This is typically solved by putting ...
Think of it like a road trip without GPS. You come to an intersection, and think you need to turn, but aren't completely sure. So you take the turn, but ask your passenger to check the map. Maybe you're three miles down the road by the time you finish arguing about where you are. If you were right, you're three miles farther than you would have been if ...
It is not related to game programming. Some scientific code can also use both the GPU and the CPU.
With careful -and painful- programming, e.g. by using OpenCL or CUDA, you could load both your GPU and your CPU near 100%. Very probably you'll need to write different pieces of code for the GPU (so called "kernel" code) and for the CPU, and some boring glue ...
It seems you are looking for shortcuts not to try out the "purest naive implementation" first, and directly implement a "more sophisticated solution because you know beforehand that the naive implementation will not do it". Unfortunately, this will seldom work — when you do not have hard facts or technical arguments to prove that the naive implementation is ...
Here is a general purpose tree traversal implementation that doesn't use recursion:
public static IEnumerable<T> Traverse<T>(T item, Func<T, IEnumerable<T>> childSelector)
var stack = new Stack<T>();
var next = stack.Pop();
yield return next;
First note that one major effect of inline is that it allows further optimizations to be made at the call site.
For your question: there are things which are difficult or even impossible to inline:
dynamically linked libraries
dynamically determined functions (dynamic dispatch, called through function pointers)
recursive functions (tail recursion can)
If a certain level of performance is necessary (a non-functional requirement), then that should be a design goal from the start. E.g. this can influence which technologies might be appropriate, or how you structure the data flow in the program.
But in general, it is not possible to optimize before the code is written: first make it work, then make it right, ...
Of course the condition is checked every single time. You cannot avoid this.
Branch prediction and many other tricks that modern CPUs do are all about achieving as much processing as possible in parallel. One of the main features that accomplishes things in parallel is the CPU pipeline. When the pipeline is full, you get the most benefits. When the pipeline ...
Without reading anything but the title: Yes.
After reading the text: Yes. Though it is true that maps and shared pointers etc. do not perform well cache-wise, you will most certainly find that what you want to use them for — as far as I understand — is not the bottleneck and will not be held in or use cache efficiently regardless of the data structure.
The answer to the question you actually asked is no, but the answer to the question you meant to ask is yes. Adding parentheses does not slow down the code.
You asked a question about optimisation, but parentheses have nothing to do with optimisation. The compiler applies a variety of optimisation techniques with the intention of improving either the size ...
Performance optimization doesn't lend itself to these kinds of generalized rules, and I'm not sure that the rules you proposed were ever good ways to optimize.
Here's a better plan:
Set specific performance requirements. (i.e. define "good enough.")
Start with well-written code that takes advantage of routine performance optimizations such as sensible ...
This isn't a law of nature, but a rule of thumb born out by wide experience. It is also known as the 80/20 rule, and is only ever a rough approximation.
Loops, Branches and other flow control.
Each place that has an if, you will have one branch that is taken more often than the other branch. Thus more of the execution time is spent executing that part of ...
In general, no, you shouldn't avoid creating objects for fear of performance loss. There are several reasons for this.
Using objects is kind of the point of using Java. Avoiding them preemptively is a sign that the decision to use Java might not have been the right one to begin with.
Performance issues are notoriously hard to predict. Never assume that ...
TL;DR: Pass by const reference is still a good idea in C++, all things considered. Not a premature optimization.
TL;DR2: Most adages don't make sense, until they do.
This answer just tries to extend the linked item on the C++ Core Guidelines(first mentioned in amon's comment) a little bit.
This answer does not try to address the issue of how to ...
Ask yourself this:
Is the software NOT meeting performance specification?
Does the software HAVE a performance issue?
These are reasons to optimize. So, if people are opposed, just show them the specification and go back to them and explain we need to optimize because we are not meeting spec. Other than that, one would have a hard time convincing others ...
Seriously, premature optimization can be a problem - you might wind up spending hundreds of hours optimizing a routine that is only run once/week. Also, fully optimized code is often harder to read and debug.
Consider - you can spend a couple of days the processes 10,000 records per minute. It's easy to read, easy to maintain, easy to test.
When it comes to large if blocks, optimization isn't really an issue. The compiler will generate pretty much the same result no matter how you organize them, assuming that the conditions are equally easy to calculate.
One technique I like to use is to use "guard statements" to check for invalid input right away, at the top of the method body. This way, the ...
Linking code (using the linker, e.g. ld often started by gcc or gfortran compilation commands) written in two different languages is implementation specific. It is often called foreign function interface. It depends upon calling conventions specific to the implementations.
On Linux, with code compiled by gfortran and gcc (both from the GCC compiler) is ...
I'm tempted to stop there! :-)
Consider this program
2. loop 10 times
4. loop 5 times
Line 1 is executed once whilst line 3 is executed 10 times. Looking at each line in turn
1 1 0.8%
2 10 8.3%
3 10 8.3%
4 50 41.3%
5 50 41.3%
Two lines account for 83% of the execution time (...
Yes, memory alignment still matters.
Some processors actually can't perform reads on non-aligned addresses. If you're running on such hardware, and you store your integers non-aligned, you're likely to have to read them with two instructions followed by some more instructions to get the various bytes into the right places so you can actually use it. So ...