What's the deal with Deno? We talk with a major contributor to find out. Listen now.
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 ...


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


61

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


54

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.


41

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


37

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


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

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


31

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


29

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


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

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


23

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


23

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


22

It's actually quite an easy choice. Right now, you have zero users, and scalability is not a problem. Ideally, you want to reach the point where you have millions of users, and scalability becomes a problem. Right now, you don't have a scalability problem; you have a number-of-users problem. If you work on the scalability problem, you will not fix the ...


22

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


20

The existing answers focus on ISA changes. There are other hardware changes, too. For instance, C++ commonly uses vtables for virtual calls. Starting with the Pentium M, Intel has an "indirect branch predictor" component which accelerates virtual function calls.


20

Of course the condition is checked every single time. But by the time it is checked, it is far up into the CPU pipeline. In the mean time, other instructions have also entered the pipeline, and are at various stages of execution. Usually, a condition is immediately followed by a conditional branch instruction, which either branches if the condition ...


20

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


18

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


17

There's a simple order rule of three: Get it right. Correctness is paramount, something that does the wrong thing fast or beautifully is useless. This has to go deeper than "oh this seems to work okay" - it has to really work reliably for the entire domain of application that you are intending to use the code for. Get it nice. Elegance and simplicity of ...


17

Both :-) 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. Or, ...


17

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


17

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


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