Expensive code does not necessarily mean code which uses lots of memory, it also means code which runs really slow or otherwise bogs down the overall performance of your place.
You can use the script performance tool built into Studio to look at some of that performance info:
The names of your scripts are on the left. The Activity of a script tells you how expensive it is to run. Lower is better!
This is indeed helpful but there are times when we need to measure a small section of Code.
Script Performance measures how entire Scripts runs
It is a useful tool to pin down which script is causing problems in a game that has many Scripts, however If I have only 1 Script then finding which small section of Code is causing problems couldn’t be done with Script Performance
Do you currently have a performance problem or are you trying to do premature optimization? You shouldn’t worry about optimization until you actually have a problem.
Premature optimization is not good practice at all. It often leads to utterly unreadable code.
I’m not saying to flail your arms on the keyboard and write whatever gets the job done. Don’t write wasteful loops or do intentionally terrible things. Write the smartest code you can without sacrificing readability. Only if you start to see players having problems do you find and optimize what’s causing the problem.
You can use the script performance panel mentioned above to get a clue as to where problems might arise. You can use the microprofiler to see execution time of code chunks. You can analyze code for time and space complexity. But all of this is still subjective and should only be optimized if it’s a problem.
They are correct in saying that you shouldn’t optimise before you have performance issues. However, something they missed is you should test your game on different devices before release, especially low end and mobile devices.
If any performance issues come up when you test your game on different platforms, that is the time to start optimising. If you optimise before there’s any performance problems, all that ends up happening is your code becomes less readable and maintainable, and potentially more error prone.
I would never write code in such a way that compromises my code even more, no one should do that.
I believe that it is important knowledge for specific topics for example using BindToRenderStep, in this case the better your code runs the better it is for the game in general.
Another Example would be FPS games where a Gun Script Performance is crucial and will effect User Experience and Game Play.
I don’t think you will find answers to the “is it expensive” questions being asked in those links in your list by adding up the memory footprint of variables in your game (if that’s even possible with a script… A Boolean in Lua is almost certainly a class, and way bigger than a bit, with other overhead, etc). That said, the Memory Analyzer is another good resource if you need to look into memory usage. Too many textures, in particular, can be a problem with mobile it would seem.
Answers to performance questions can be highly specific, and solutions can often require design trade-offs between a handful of options that have been exposed to the script writer through the API. There isn’t really a catch-all solution, which is why there are so many threads that seem to ask almost the same thing.
When you run into a performance issue, try the things that Elttob suggested (and search for solutions that others have already worked out for the same or similar problems), and then post your own question about your specific issue. That’s what I would do.
Developing performant solutions to interesting problems is not usually a task that a typical script writer should stress over at length. Identify the problem, play around with options until you run out of ideas, and then lean on your Comp Sci neighbors for advice.
That doesn’t mean you micro optimize your guns. If your guns work fine and responsively the first time you code them (without express thought of max performance), you DON’T micro optimize it.
Don’t optimize until you have a problem. Test on mobile devices to see if you have a problem.
You shouldn’t go by rough ideas of what you think would constitute a type. A Lua boolean is probably more around 4 bytes (not counting the TValue overhead Lua has). This kind of analysis of memory is probably not what you’re looking for; it won’t always be exact/the same.
Unless there’s a built in specialization for the language you’re using for memory efficiency, this is not the case. Platforms tend to pad their types to their register size. It’s also dependent on context, so it’s not something to worry about unless you’re dealing with large collections.
4 bytes, so 32 bits. Double that on 64 bit programs.
Isn’t the larger size a direct result of the lack of static typing in (scripting) languages? I’d imagine you can’t (afford to) allocate less than the size of a pointer for any variable without it.
I can’t speak for every implementation, but Lua’s TValues are a tagged union, so naturally their size is padded to their largest non-gc type, which is usually doubles. It’s the overhead you pay for having a language where variables can change type, yes. Static typing in a scripting language also probably wouldn’t fix it because you’d still be using its underlying stack impl.