Well, it's not the prototyping how you determine the performance in game projects, but by early optimization of the final implementation. If you were doing more research type of work, then you would do prototyping, but that's not what you do in game projects in general.
A prototype can also be made using engine code that is still unfinished, but then it's done in a different branch of source control. If it works out as expected (i.e. meeting design goals) then it's further developed into production quality code and then merged back into the trunk, else discarded. What you describe sounds like doing optimizations straight in the trunk, which is a very bad idea not unlike premature optimization.
Even if you are experienced programmer you have to learn what are the performance characteristics of your target platform to be able to write efficient code straight.
I have a bit more faith on those less experienced programmers, but I wasn't talking only about them. [...] I'm not writing a newbie programmer tutorial here but just sharing my experiences I have had regarding the topic...
The problem I have is that your experiences could put both newcomers and experienced programmers on the wrong track (but most likely the former). The way you describe it, the advice about premature optimization is incorrect for certain aspects of game development, advocating to optimize things without prior information about whether it will be gainful or not, right?
Now consider the possibility that you've been fairly lucky with your assumptions and it never lead to serious project delays. Or take it as a complement; intelligent people are more likely to make better decisions for a complex issue having only little prior info. But with all due respect that doesn't prove that your advise is any good.
In my experience development is faster to some degree if you stick to Knuth's advice. My number one experience is being the lead developer of SwiftShader, a real-time software renderer. And I believe that's relevant because performance is never high enough and there are always more features to implement. So I can't afford to waste any time optimizing something I'm not sure will give me any significant gain. In almost a decade the only recipe that has proven to work is: profile, prototype, optimize.
You could argue that I've proven nothing either but then I'd have to ask you to find a faster software renderer with the same feature set that has been written by a small team. I don't want to make this any more personal than necessary though. But keep in mind that Knuth has also been awarded the Tokio Prize for lifetime achievement so you still have a lot of proving and disproving to do.
...hoping to spawn some fruitful conversations.
I think you definitely achieved that already. :yes: Also please note that even though I don't fully agree with you I certainly appreciate that you share your experience and defend it. :happy: Maybe in the end we all learn something. It already made me have a closer look at the exact definition of premature optimization, only to discover that it applies exactly as much to game development though...