I'm once again stumbling into the forums as my own beliefs have been challenged by code examples in the wiki,
I'm wondering what the performance cost of some functions such as love.graphics.getWidth(), love.mouse.getX(), or love.timer.getTime() are.
When I first started working with Love2D, I assumed that I should save these into variables so that I don't call these functions repeatedly causing minuscule loss of processing cycles, and instead just sacrifice some memory for it. My current contrasting belief has been that I shouldn't add useless variables to my code and use minuscule amounts of extra memory, since these functions probably just provide variables from memory.
However, as I've been looking at the examples in the wiki, I see them save results from functions that provide a single variable, so I'm wondering what the actual performance impact of calling these is? Are some of such functions simply recalling variables from the framework, or do they all do calculations to provide the value? I assume calculation would be done for getTime() for example, but for the others I'm not so sure.
I'm aware that whatever the performance impact of these would be, it would in most cases the negligible, unless they get called so many times, but I'm looking for peace of mind regarding this.
TL;DR: Should I save the returns of functions such as love.graphics.getWidth() to variables if I'll use them multiple times?
Performance cost of built-in functions returning single values.
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
- fakedeltatime
- Prole
- Posts: 3
- Joined: Sun Oct 28, 2018 2:45 pm
Re: Performance cost of built-in functions returning single values.
This is the answer. It doesn't matter in most cases. The performance bottleneck in your program is usually not going to be caused by some function calls (with exceptions, of course). If you suspect a specific LÖVE function call might be expensive, just measure how much time and memory it uses, or look directly at LÖVE's source code. Looking at love.graphics.getWidth() we can see it simply returns an existing value, but Font:getWrap() is doing a whole lot more.fakedeltatime wrote: ↑Thu Mar 31, 2022 6:32 am I'm aware that whatever the performance impact of these would be, it would in most cases the negligible
Reasons to call a function once and store and reuse the value include:
- Nicer/shorter/clearer code elsewhere.
- The returned value may change between calls (e.g. love.timer.getTime()).
- Loop or JIT compilation optimizations.
The real loss here is worrying about small stuff like this - not in actual performance in the program.
Also, regarding examples in the wiki... they only show how something could possibly be done, not how things should be done most optimally (which might be different in different situations, if it even matters at all) or the most clearly (which is important when working with other people on the same code base, including your future self when you revisit the code).
Tools: Hot Particles, LuaPreprocess, InputField, (more) Games: Momento Temporis
"If each mistake being made is a new one, then progress is being made."
"If each mistake being made is a new one, then progress is being made."
- zorg
- Party member
- Posts: 3470
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
- Contact:
Re: Performance cost of built-in functions returning single values.
Besides, the wiki does have clear indication in the form of those yellow boxes for methods that do have a noticeable impact, mainly the constructors for Object subtypes (newImage, newImageData, newSource, newVideo, newDecoder, newSoundData, etc.), saying they shouldn't be called in love.update or love.draw... but also mentioning in general that they can be slow.
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
Re: Performance cost of built-in functions returning single values.
Also see:
viewtopic.php?f=5&t=92757
viewtopic.php?f=5&t=92757
My boat driving game demo: https://dusoft.itch.io/captain-bradley- ... itius-demo
- fakedeltatime
- Prole
- Posts: 3
- Joined: Sun Oct 28, 2018 2:45 pm
Re: Performance cost of built-in functions returning single values.
The yellow boxes are really clear, yes, but I was wondering this for the less performance intensive methods, which probably should never be a problem unless the code using it is bad enough to cause a problem, but I just got this bug of wanting to write more, even if it's slightly, efficient code when I can.
Thank you for pointing out that I can go look at the source code for the methods, I'll do that from now on when I stress myself over these useless things! I've been using the timers to try to measure the impact of these, but the values are so small that the discrepancies are too great for the numbers to be of any use (once again showing that worrying about these is pointless).
Thank you for pointing out that I can go look at the source code for the methods, I'll do that from now on when I stress myself over these useless things! I've been using the timers to try to measure the impact of these, but the values are so small that the discrepancies are too great for the numbers to be of any use (once again showing that worrying about these is pointless).
Re: Performance cost of built-in functions returning single values.
A function call will take more time than accessing a local variable.
I would save the values for readability and ease-of-typing anyway. Do you really want to type "love.graphics.getWidth(), love.graphics.getHeight()", etc., over and over again? Personally I try to keep my lines no more than 80 characters long.
I would save the values for readability and ease-of-typing anyway. Do you really want to type "love.graphics.getWidth(), love.graphics.getHeight()", etc., over and over again? Personally I try to keep my lines no more than 80 characters long.
Who is online
Users browsing this forum: Google [Bot] and 7 guests