ivan wrote: ↑Thu Oct 25, 2018 4:29 pm
Sure, your program will be slower when profiling - you should only use the profiler when debugging.
This is because all function calls are hooked and tracked by the profiler.
Apart from loading, each frame of your game should never take longer than 10-30 milliseconds to execute.
Even if your game is not playable, you can still check the profiler report to see WHY your code is not playable.
Yeah, my player and enemies fall down and ignore HC collisions (Overload,I think it happens because I use 2 maps in memory with respective layer update and draw)..., but I can see the report and see what function are used and how often
grump wrote: ↑Thu Oct 25, 2018 7:39 am
I'd like to add that you should not waste time doing premature micro-optimizations (pairs, local variables, etc.) until you have found the real bottlenecks in your code. Most tips in this threads are micro-optimizations, and they won't save a badly performing game.
The most important advices here are a) use a profiler, so you actually know what's eating performance instead of just guessing (because you will guess wrongly), and b) don't draw things that aren't on screen, which is a logical extension of "don't process things that don't need processing". You can save the micro-optimizations for later.
When the damage is already done (meaning the application is already slow), I agree that using a profiler to show the bottlenecks and focus on them is a sound advice.
But you can work on some micro-optimizations as you code, with little effort, and that can pay off later.
pgimeno wrote: ↑Thu Oct 25, 2018 6:25 pm
But you can work on some micro-optimizations as you code, with little effort, and that can pay off later.
Oh yes, that is absolutely true. Once you've learned the problematic language constructs, it becomes (or rather, should become) a habit to automatically avoid them while writing code. For example, I'm never using ipairs anymore to iterate over proper arrays, I prefer to use for i = 1, #array instead.
Recommended reading: The fallacy of premature optimization, by Randall Hyde
Good read:
Randall Hyde wrote:People accidentally give up performance when they don't understand the costs associated with the constructs they are using in their programs. By studying how systems translate or interpret high-level language statements, you understand the costs and will not use inefficient constructs because you don't know any better.