LÖVE

If you visit stack overflow or any other such forum, in every thread about performance, every single time you see the most upvoted post reciting that quote and saying not to bother with this over a chance that it will not be too bad by the time it's finished. It's even in threads where the guy asks for hard data on very specific topic and not some general advice - they didn't come there to be schooled on something this basic, they came for straight answres, and they still get that stuff and it still gets upvoted. So yes it is being said all the time, and more often than not it's when it's completely inappropriate.

While it is true that optimizing for the specific solution you have right now is a poor strategy because then you'll arrive at a different solution needing its own optimization, repeat ad nauseatum, knowing well in advance what things are fast and what things are slow often helps avoiding building code that's slow at, and I stress, no expense. It's one thing if you use poor algorithms, but if you use operations that are just not meant to run fast and never will is when you use something different that is fast. E.g. using dynamically generating strings to access table keys in Lua. You shold instead use sub-tables or at least a computed number.

I totally agree... But this is a general question that is why I cited that line, after saying stuff like "draw calls are expensive" "use spritebatches and canvases when possible" "avoid repeating data" etc... I don't think I was trying to dismiss that writing good code and knowing what stuff is fast and which isn't is good, actually it was the other way around.

But it still should be noted as you said, that optimizing without a complete idea of the whole scope will probably lead to a huge loop of optimizing a part of the code and making other part slower, and will probably get nothing finished since it will probably take more time than writing the game itself... this are the reason why that quote applies to this specific topic.

In general the questions had been answered

Positive07 wrote: ↑Tue Feb 14, 2017 10:16 pmAlso the person who are crazy for optimizing seem to try to look smart too, if there is no need to optimize why would you lose your time anyway? Are you gonna tell me that if a beginner writes a PONG game it should be optimized to the core and run at 1204FPS? If the game is simple enough there isn't any benefit in optimizing...

If he wants to, sure.
If he wants to give himself a challenge to see how smart he can get with algorithms to make it run even better, sure.
Optimization helps you learn how to do all sorts of things in various different more efficient ways, so there IS a benefit in trying your best to optimize stuff, especially when learning new things, like that PONG game you mentioned that most newbies make. Why are you encouraging people to not take the chance to try their best, to try and learn smart new ways of doing the same task, especially when that person is still learning something?

Encouraging people to not optimize their code until they hit an insane bottleneck is bad practice, and you should feel ashamed if you spread the same message.

Obviously performing micro-optimizations in commercial projects should not be done unless it's really necessary, but shying away from macro optimizations, especially in places where it can be seen to the naked eye, is just stupid. There's no idiom or phrase that will make ignoring obvious macro optimizations not a stupid choice, or justify it in some way.

Ugh how annoying... have you even read the comments? We have being saying people should learn your way around LÖVE, should learn what is more performant and what isn't, should learn how Lua works, and what are the pros and cons of tables, garbage collection, function calls etc... You should learn all this in order to write good code that doesn't get into bottlenecks easily, you should also learn to write good, readable code that is easy to maintain.

But this isn't optimization so I consider optimization not to be important. Yet I'm not saying that you should hit bottlenecks or that you should write bad code so I'm not ashamed of the message I'm conveying.

Yes it's true that optimizing is sometimes needed because there is code that is really expensive like collision detection and handling thousands of moving units, or raycasting and such... Yes, I know that there are structures that are better than others and that when you have huge structures of data, a simple for loop may be better than an ipairs loop and thousands of time better than a pairs loop... I know all this, but most of the time pairs is not the bottleneck, so optimizing is not always the answer, using pairs for readability's sake is also allowed.

I think that telling a person that has just come to an engine to learn to optimize even before making a game just because he should learn it, is a bad practice and you should feel ashamed of it. It's a loss of time when you are just trying to make a simple PONG to learn how the engine works.

In a completed game, optimization is good, yes, it's hard but you already know what does each part do, and how they are interconnected, you know what is slowing the game down and you know what features you need to get in each module... If you wrote readable and maintainable code then you can come later and revisit to bring better performance to each part of the code.

Whatthefuck wrote:There's no idiom or phrase that will make ignoring obvious macro optimizations not a stupid choice, or justify it in some way.

Actually, there is. The phrase is "tradeoffs," and you can justify it like this: say you have a game that runs at the target frame rate on the target hardware. You've designed it in such a way that redundancy is kept to a minimum, loose coupling, high level of reuse, and so on. In case this is hard to imagine, here's an example: you might have employed a Lua-esque take on ECS, where tables represent entities, fields represent components, and functions represent systems. If done properly, this design strategy gives you all the benefits mentioned, but at a cost... it won't be "hyper-optimized," because you've traded some runtime efficiency for a more tenable code base (in fact, you've already made a very similar tradeoff by using Lua instead of C, or C instead of assembly).

If you used regular Lua language constructs to achieve your design goals, without a layer of abstraction, you don't really have the option of keeping the same API and just optimizing the internals. So if you want to optimize certain aspects of it, you'll be making the trade in reverse – you'll be gaining some runtime performance, but making things more difficult to maintain, or reuse, or reason about. At the end of the day, if your game was already hitting its mark in terms of performance, optimizing it further is trading something useful for something you don't need (assuming there's any cost at all associated with optimization, which there probably is, if nothing other than more code to maintain).

Of course, if it's not hitting the performance mark, then it's time to optimize it.

If it's only functions you can organize it and separate them "require" to not get too disorganized, imagine a java importing hundreds of libraries and each presenting several lines and pulling other libraries, this does not affect the performance if your processor with memory (min 1.5 GHz / 1GB for example) is the minimum of our reality, not those of 15 years ago. The framework supports colossal functions that will present thousands of lines. The problem will not be there, but in the files besides the functions (audio, video, images) when they will be loaded in load(), of course, you need a load and if they are of high quality (size), then you notice something In most of which are minimal.