120

Micro-optimization is only important if the numbers say it is. The requirements that you are developing against should have some specification of performance data, if performance is at all an issue to the client or user. As you are developing software, you should test the performance of your system against these requirements. If you aren't meeting ...


118

You cross the line when You have measured that your code is too slow for its intended use. You have tried alternative improvements that don't require mucking up the code. Here's a real-world example: an experimental system I am running was producing data too slowly, taking over 9 hours per run and using only 40% of CPU. Rather than mess up the code too ...


115

Where? On a home page of a Google-scale website, it is not acceptable. Keep the things as quick as possible. In a part of an application which is used by one person once a year, it is perfectly acceptable to sacrifice performance in order to gain code readability. In general, what are the non-functional requirements for the part of the code you're working ...


103

Whenever anyone asks about optimisation, I'm reminded of the quote from Michael A. Jackson The First Rule of Program Optimisation: Don't do it. The Second Rule of Program Optimisation (for experts only!): Don't do it yet. Quote from Wikipedia corrected for British English. *8') Implicit in the second rule is to profile your code and only spend time ...


90

I both agree and disagree with your father. Performance should be thought about early, but micro-optimization should only be thought about early if you actually know that a high percent of time will be spent in small CPU-bound sections of code. The problem with micro-optimization is that it is usually done without having any concept of how programs actually ...


87

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 ...


84

Write code, that is clean, concise, simple and self-explanatory. Make performance tests to identify bottlenecks. Optimize critical sections. As a rule of thumb: 95% of your code is run 5% of the time. There's no point in optimizing before you profile/benchmark your code and see which are the 5% that are run 95% of the time. Every idiot can do micro-...


62

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 ...


57

It's a false dichotomy. You can make code fast and easy to maintain. The way you do it is write it clean, especially with as simple a data structure as possible. Then you find out where the time drains are (by running it, after you've written it, not before), and fix them one by one. (Here's an example.) Added: We always hear about tradeoffs, right, such ...


52

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 ...


46

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.


44

"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 ...


38

I'm surprised that this question is 5 years old, and yet nobody has posted more of what Knuth had to say than a couple of sentences. The couple of paragraphs surrounding the famous quote explain it quite well. The paper that is being quoted is called "Structured Programming with go to Statements", and while it's nearly 40 years old, is about a controversy ...


37

People often say this (somewhat tongue-in-cheek, in my experience) as a dig against C++ as a choice of language. People typically choose C++ because it is, in most cases, faster than an alternative like Python or Java. However, most of the time, the additional speed gained is not really needed. When a person says "Programming in C++ is premature ...


36

Usually, no. Changing the code can cause unforeseen knock-on issues elsewhere in the system (which can sometimes go unnoticed until much later in a project if you don't have solid unit and smoke tests in place). I usually go by "if it ain't broke, don't fix it" mentality. The exception to this rule is if you're implementing a new feature that touches this ...


36

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 ...


35

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 ...


34

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 ...


33

Doesn't the browser already do this for you, and probably better?


31

In my OSS existence I do a lot of library work aimed at performance, that is deeply tied to the caller's data-structure (i.e. external to the library), with (by design) no mandate over the incoming types. Here, the best way to make this performant is meta-programming, which (since I'm in .NET-land) means IL-emit. That is some ugly, ugly code, but very fast. ...


29

In Brief: it Depends Are you really going to need or use your refactored / enhanced version? Is there a concrete gain, immediate or long-term? Is this gain only for maintainability, or really architectural? Does it really need to be optimized? Why? What target gain do you need to aim for? In Details Are you going to need the cleaned up, shiny stuff? ...


28

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 ...


27

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, ...


26

When you've profiled the code and verified that it is actually causing a significant slowdown.


26

I would agree with your father: "If a coder does not consider performance in their code even at the micro level, they are not good programmers." The key is to "consider performance". That is not equivalent to "do micro-optimizations at every step". I agree with most of the other comments - what used to make C programs faster may not do so today - but there ...


26

However, with all of these new systems, it seems as if GPUs are better than CPUs in every way. This is a fundamental mis-understanding. Present GPU cores are still limited compared to current top-line CPUs. I think NVIDIA's Fermi architecture is the most powerful GPU currently available. It has only 32-bit registers for integer arithmetic, and less ...


26

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>(); stack.Push(item); while (stack.Any()) { var next = stack.Pop(); yield return next; ...


26

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. ...


25

Let's first take your case: PHP I don't think PHP is a kind of language (both because of its nature and its main domain of application) that you need to worry about these "micro-optimizations". PHP code is mostly optimized with opcode caching. The programs written in PHP are not CPU bound, they're mostly I/O bound, so these optimizations won't be worth your ...


Only top voted, non community-wiki answers of a minimum length are eligible