Heh, "squeezing".

How does a programmer squeeze the performance out of a console

The same way you would any other platform—profile and fix.

and is it a collaborative effort?

No matter what the company or situation is, it is always best if all people can write competent code with no obvious pitfalls.
But not only does that never actually happen, there should still be at least one guy who is really good at and mainly focuses just on performance, at least for big projects.

Is squeezing performance out of a console the same as premature optimization?

No, and depending on who you ask, “premature optimization” is a misnomer in the first place.

Is squeezing performance out of a console done fairly on when the game is being developed for the console or when the game is halfway done or when the game is closed to the deadline?

How many do this and at which time in a project they start doing it may vary.
At tri-Ace that is my main job and I do it during around the second half of each project.

Is there any similarities with squeezing performance out of a console versus optimizing an application?

They are the same thing, unless you are talking about actual techniques involved.
For example:

for ( int i = iTotal; --i >= 0; ) {}

Works very well in Java, so you always want to use that in Java Android apps.
Works pretty well in x86/x64, so you generally want to use it on desktops.
I hardly notice a change on iOS devices and Nintendo 3DS.
Often fails on PlayStation Vita (even though it is also ARM)—it seems only to be faster when i is not used as an index inside the loop.
If you are going down to the level of ASM, they are very different.
Different intrinsics, different sets of assembly instructions, and in the case of Nintendo 3DS vs. conventional ARM VFP the syntax is different (it more closely matches how the assembly looks in the final product, which I prefer, except that it makes it impossible to use for a lot of things because you have to know the register of a variable, and you don’t).

Does the premature optimization rule still hold today?

That “rule” has done more damage than good for the same reason the “don’t write engines, write games” “rule” has.
In fact, you are a perfect example of it:

But I figure optimizing something like collision logic in my game will help the game performance. While I ran the game with or without the optimization, I have not seen any noticeable difference but the time I used up was probably 2 minutes so no harm was done

Some people are paranoid that what they are writing could be a game engine because they read an article telling them not to write game engines.
You’ve been raised to fear this thing called “premature optimization”, so now you are sitting here worried that you may have done it, but justifying it by saying it was just 2 minutes’ worth of your time.


Many people go beyond that and seem to almost intentionally write slow code or at least specifically avoid obvious little things they could do just because they are afraid of it being coined “premature”. For example, as long as the order of your loops don’t matter, in Java you should almost always use the loop I showed above.


But the real harm from “avoid premature optimizations” comes later when you decide to finally start optimizing.
Sometimes there will be a clear algorithmic bottleneck, but once you get those out of the way you are then looking at a sea of functions/methods in which there does not seem to be an obvious one to tackle next.
Perhaps you see a bunch that are taking 5% of the CPU and you feel content, oblivious to the fact that they should all be taking 4% or 3%.
Or that one that is just a bit high but you aren’t so bothered by it because it just peaks over everything else. Little do you realize it would be towering over the rest if proper attention to performance had been taken from the start.


A “premature” optimization is a destructive optimization.
It’s an optimization that either makes things slower or causes bugs.
It’s also subjective and it depends on your skill level and experience.
If it is your first time writing a new algorithm you should probably not try to heavily optimize every little part along the way. Make it run, then make it fast.
But if you have written it before, or even many times before, you may very well be justified in having an extra focus on optimizations from the very start.


And there is more.
Don’t be apologetic for spending 2 minutes even though you didn’t see a result.
You will never write fast code unless you try and fail or try and succeed (in other words, unless you try).
When you fail you gain a sense of what not to do in the future.
When you succeed you start to feel better about certain assumptions, such as that the for-loop I posted above is a better default loop than “for ( int i = 0, i < iTotal; ++i ) {}”.
Doesn’t mean it is always the faster loop but if you have to pick one or the other as a default you will win more times than not via the counting-down loop.
Something you learn in time by trying.



Just code.
You don’t always need to worry about making it fast, but you should never worry about not making it fast (not to be confused with making it slow; they are not the same thing).


L. Spiro

+1 for L. Spiro, Although premature optimization is the root of all evil: good programmers are lazy, and wasting your time optimising things that don't matter is a bad hangover I see from ASM programmers in the past (I started just after that, PS1 time). Use a profiler, optimise what takes the most time to run.

Picking a better algorithm normally beats low level optimisations anyway.

A “premature” optimization is... an optimization that either makes things slower or causes bugs.

It's also pretty much any optimisation that influences architectural decisions early in your project.

The cost of large refractors increases dramatically as a project progresses, which makes it imperative that your architecture be sound from the get-go. If you compromise early on architecture because of beliefs about performance, you risk paying the refactor tax many times over. Performance hotspots tend to change over the course of development, whereas architectural challenges don't.

For me, a premature optimization is an optimization that adds complexity to the code and possibly makes it harder to read that's made before it has been determined that such an optimization is even needed. There's nothing wrong with writing fast code and optimizing early. I always try to do this, but after examining my projects needs, sometimes I choose the easier albeit slower implementation/algorithm over the faster and more complicated (and potentially buggier) one. If later I find that it's a bottleneck, I'll change it then.

When working on hobby projects as the lone coder, this is important. Take this example. A programmer is working on a simple 3D game and uses a 2D array to keep track of his objects locations in 3D space. Its simple and it works well, but he hears that 2D arrays are slow and quad-trees are faster so he changes his code. He's new to quad trees and adds a bunch of bugs. He's not sure if the bugs are from the quad tree or other parts of the code. On top of that, we didn't even have that many objects so using 2D arrays was actually more than fast enough for his project.

(1)
It's also pretty much any optimisation that influences architectural decisions early in your project.

(2)
The cost of large refractors increases dramatically as a project progresses, which makes it imperative that your architecture be sound from the get-go. If you compromise early on architecture ..., you risk paying the refactor tax many times over.