noob questions: does number of lines of code affect speed of a game?

[yougetagoldstar]

Hi again. While trying to learn all this stuff questions like these pop into my head:

Wondering if many lines of code can negatively affect game speed in some way.

since love2d only uses 2d graphics, is it only memory usage that causes slowdowns and not-optimal gameplay? Did I even word that right?

Is this the same with number of functions? do functions use up more memory or are they more memory efficient?

Is it true that tables use up a lot of memory? Should I only use them when I absolutely need them?

How well does lua and love2d handle a trillion functions and variables?

is all of this so trivial with today's computers that it doesn't matter?

If you feel like answering, any input is welcome, as I know little about the technical side of game making. feel free to share your thoughts!

[Sulunia]

Wondering if many lines of code can negatively affect game speed in some way.

What will matter is how many functions you call/calculations/iterations you do inside the current update and draw loop your game is running. The amount of parallel threads may also slowdown your game. So long as you don't put huge table iterations on the update loop or do very intense calculation stuff on the main thread, you're good to go. This is a basic explanation, perhaps someone can further elaborate.

since love2d only uses 2d graphics, is it only memory usage that causes slowdowns and not-optimal gameplay? Did I even word that right?

Definitely not. But i'll avoid trying to explain why, since i'll probably say something wrong. But i can say that running an unoptimized update loop can also slowdown your game.

is all of this so trivial with today's computers that it doesn't matter?

I'll be frank with you, just code your game. If you worry so much about optimizations beforehand, you'll never get started. Make things work, then worry about how to get things running more smoothly eh?

[MrFariator]

Wondering if many lines of code can negatively affect game speed in some way.

More lines of code means the computer needs to do more computations. However, the raw number often times (or basically always) matters less than what you're actually doing. For instance, string manipulation is going to take far longer than some simple arithmetic (ex: concat two strings vs summing two values together), but this stuff is still measured in basically microseconds on modern computers.

since love2d only uses 2d graphics, is it only memory usage that causes slowdowns and not-optimal gameplay? Did I even word that right?

If there are slowdowns it typically will be something that wasn't optimized or poorly implemented. For example a shader effect might be doing too many computations when particle effects clutter up the screen, leading to slowdowns. Not so much a memory problem but rather the number of computations the game had to manage to keep up.

Is this the same with number of functions? do functions use up more memory or are they more memory efficient?

This is a more complicated topic and would require delving into how programs manage memory. However, the primary reason to use functions in the first place is the reusability of code that they provide, not so much that it makes memory easier to manage. Why write some piece of code over and over, when you can have a single function to handle that case?

Is it true that tables use up a lot of memory? Should I only use them when I absolutely need them?

They do take more memory, but even that depends on what you put into those tables. Basically the more stuff you give 'em, the more memory they consume, but it's far easier to manage than having the same number of variables littering about outside a table. For basically most use cases you'll probably think of, you are not going to run into any troubles, even when you have some thousand elements in a table.

How well does lua and love2d handle a trillion functions and variables?

I think there might actually be some hard limits on how many local or global variables you can have in lua, but you really shouldn't worry about them. In fact, I'm pretty sure most if not all programming languages would start getting headaches at such arbitrarily high numbers as trillions. Of course, again, the raw number matters less than what actually goes on in the code.

Most importantly remember: premature optimization is unnecessary. Optimize when you actually run into bottlenecks.

[Positive07]

is all of this so trivial with today's computers that it doesn't matter?

No, it's not trivial, you should consider your memory usage, you should try to avoid duplicate data, and optimize the memory structure of your tables, you should also try to minimize the number of assets using spritesheets, and having MANY draw calls will slow your game, I think 4000 draw calls will drop the FPS under 60, there are ways to optimize that with SpriteBatches and Canvases

But all this is actually trivial, why? because if you have no game then there is nothing to optimize, and even if you did have a game, if it doesnt slowdown then there is no need to optimize, optimization is a pain, will probably be hard, you may run into edge cases, your code may become more complex and you may have trouble understanding it, you would end up more time optimizing than creating your game and you would end up with no game at all, this the reason premature optimization is the root of all evil. So handle it with care and mostly when it is necessary.

[yougetagoldstar]

this info really helps me decide how to approach all of this. thanks all.

[raidho36]

Number of lines doesn't matter. What does matter is how many instructions you run per second - you may have 5 line function but it doesn't mean it's computationally insignificant if you run it million times per frame, right? Same thing with cramming a lot of code in a single line. Different operations cost differently, as they can (and usually do) include multiple basic operations underneath, some operations have as little as one and some execute so many it can really take its time computing stuff. But most notably you should know that producing a string by concatenation is very expensive operation, and that using a local variable is faster than using a table (all globals reside in a global table). Each addition, function call, array lookup etc. that you run cost some processing time. And on the flipside, if it just sits there it costs nothing.

The amount of memory consumed doesn't impacts performance. The number of Lua objects - does. That includes tables, strings, functions and closures, etc. - simple values like numbers, booleans and nil don't count as objects. The garbage collector has to run over all live objects to see if they're dead, and the more there are objets the longer it takes, so having lots of objects can by proxy adversely impact performance, by making garbage collector run longer. That will manifest in short freezes every so often and the freezes will get longer as number of live object increases. While it's not too bad it looks like microstutter, then it starts look like full on game freeze.

Once upon a time, someone missatributed to Bill Gates the quote "640 K ought to be enough for anybody". Well clearly you can exaust that resource easily if you don't conserve it. Same thing with CPU power. And same thing with modern hardware.

As a note, there is a quote that "premature optimization is a root of all evil" and it is a root of all evil. It implies that one shouldn't bother with performance until they hit brick wall and the software runs so poorly it can't possibly be released in that state. But also in that state it's extremely difficult to well optimize things because that usually takes rewriting most of the codebase, there's never one big bottleneck removing which can instantly solve all performance issues. But also you may never hit that brick wall and it will run acceptably well as it is. So, there's no such thing as "premature optimization", there's "designing ahead" and there's "overengineering things". So you decide if researching on Lua and LuaJIT performance quirks to incorporate them into your code before it turns into gargantuan steamroller, if at all, is pragmatic future-proofing or waste of time.

[nyenye]

As a self proclamed beginner myself, I'd say: Do some code, and read some official documentation at the time about what you are doing. Want it or not, the official docs is the best source of knowledge you could get, and there are many *Do this and not this* which your code, and you (in the long run), will appreciate.

About optimizing, I'd say that what you should be most concerned with is loops (and strings, but you know that already i guess (posts above)), and at the same time the tables that you will iterate over. If you know that a table will be iterated, make sure it's an array like table (if possible!).

As I said, docs: http://lua-users.org/wiki/TablesTutorial

[zorg]

Also, re: tables taking up much memory it really depends on what you're comparing it to; take apples vs. oranges; in a sense, both are fruit, but you can qualitatively say that one tends to be sweeter and the other tends to be more sour (there are of course exceptions).

Similarly, in contrast to C arrays (that you can define through luaJIT's FFI that löve includes) of simple types (meaning if all table values are one "atomic" type like an integer or double-precision float) tables with the same type of data do take more memory.

Comparison is always needed, in my opinion, to have any meaningful metric to decide whether one should optimize or not, on a case-by-case basis.

There might also be a bit less obvious caveats to how you code:

• In C, "arrays of structs" vs. "struct of arrays" can have gigantic speed impact depending on the type of CPU you have (L1-L3 cache optimizations, less data to swap to/from RAM means faster computation), but this may not be that beneficial if you use lua datatypes, like tables.
• With luaJIT specifically, many things are able to be just-in-time compiled, but for example, the whole inbuilt coroutine lib is not compiled by the JIT; this results in slower code if you want to use them than if you write your code without coroutines.
• And Löve in general, game devs using lua variables makes it harder to use cheatengine on due to lua's internal structure than if they FFI'd c types for stuff like player health, etc... but i only mentioned this just for the heck of it

[Whatthefuck]

As a note, there is a quote that "premature optimization is a root of all evil" and it is a root of all evil. It implies that one shouldn't bother with performance until they hit brick wall and the software runs so poorly it can't possibly be released in that state. But also in that state it's extremely difficult to well optimize things because that usually takes rewriting most of the codebase, there's never one big bottleneck removing which can instantly solve all performance issues. But also you may never hit that brick wall and it will run acceptably well as it is. So, there's no such thing as "premature optimization", there's "designing ahead" and there's "overengineering things". So you decide if researching on Lua and LuaJIT performance quirks to incorporate them into your code before it turns into gargantuan steamroller, if at all, is pragmatic future-proofing or waste of time.

That part is spot on, thank you for saying that, really, I'm so fucking tired of seeing everyone use that quote as if trying to look smart and implying that optimization should not be done unless totally necessary, as well as promoting writing terrible code, which then would need to be refactored later on in case performance is bad.

[Positive07]

No one says that, you know? It's just that it's hard to get optimization right the first time, people tend to over engineer and do unneeded stuff, plus they concern more with optimizing than writing the code, they end with horrible functions that deal with "optimized" data structures just cause maybe they can squeeze a little bit of performance but then they lose time parsing the horrible code they have been writing and come to the forum asking why they loop doesn't update the spritebatch correctly and stuff like that...

So when talking to a person which hasn't even have a prototype of a game we tend to say that line, so that instead of shaving yaks the person gets something working first, cause if there is nothing then nothing can be optimized (and that gets worst when the person ends up dropping the project). Of course optimizing is important but it's best to leave it to a little bit later (not to the end though, but when you find something that looks like a future bottleneck, or that drops performance considerably). Also optimizing unreadable code will probably make it more unreadable, so doing it at a later stage will make you read the old code and probably realize it's unreadable, rewrite it and then optimize...

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