Ive come to the point in coding that I feel like I should learn abit more about performance cost of code. Ive tried to search on the web but havent really found anything. I have had algorithms at school, but Im thinking more basic than that, Im thinking more in terms of understanding the simplest things in terms of performance(For instance, does a if() check cost performance? if so, how much?) of the C++ language than actual algorithm performance(Atleast for now).
I kinda feel like I need to learn to crawl before I can start walking :P
Does any1 have any tips to any articles or books on this topic?
We write anyone in English, not any1.
Anyway, as to your question, you probably shouldn't worry about speed of code for a while unless you're programming on PALib or something (C++ for DS library, DS is so slow that explicit bitshifts are faster than multiplication in terms of processor overhead). But yes, everything has a performance cost. Comparisons, of course, cost less than assignments/direct memory manipulation actions.
For example, bitshift multiplication is faster than the multiply operator in most cases. But it's not really necessary because bitshift multiplication is also harder to understand. In addition, the compiler often optimizes little things into even smaller ones if it can and sees fit. So if your multiplication really is that minor the compiler will handle that bitshift for you.
To be honest, I find algorithm complexity a lot more fun... your question seems very platform independent so I can't say I know of any resources for you.
You shouldn't care about small language optimizations as you can tell the compiler to optimize the code for you - and it can do far better than you could -
Checking algorithms is the important part.
I do understand bitshift multiplication to an extent(Learned it in computer/microprosessor architecture last semester). I also know the basics of algorithm performance costs.(Gone through Sedgewicks book on algorithms last semester also). Thing is: I feel like there is a gap between what I learned in C++ programming and Algorithms. I also understand the basics of how instructions and how many cycles they use on the prosessor, pipelining, blablabla.
What Im after is: What are the costs of C++ code and techniques. I feel its kinda important to understand what costs performance, before you try optimising them in combinations(algorithms).
This especially when it comes to programming smart, not only in terms of readable code, but also reusable code.
Like: Is it a bad idea to put something into a function if you dont need to? Just cause then the code u call the function from becomes much more readable?
Or: Use an extra function to hold a function, just because you want to hold the method inside the function, but you might want to change the way it works later on, or use another library(or whatever). Not saying that this is a good idea in general, but Id reeeeally like to understand these things so I can change bad habits before they become to big a part of how I think.
I just thought Id ask for a book on the subject instead of bothering everyone here with questions Id get the response:"Go read this-book" from :P
Currently Im reading on Windows Programming and I am facinated by this world right now, but I still feel that I dont know enough about the stuff Ive learned already, which is why I just wanted to see if there was such a book.
You should understand the relative costs of calling functions by pointer, calling functions directly, and calling virtual functions.
You should understand how function objects and templates can improve performance by enabling inlining.
You should also understand when and where the compiler will generate implicit (or even explicit) copies of variables.
You should learn which of the following constructors is better and why:
The compiler might inline if you ask politely. (that is, it may ignore an explicit inline command.) Any function defined in a class is automatically issued an inline request.
I'm not sure whether or not the compiler automatically inlines any function.