Lua Lag Help
-
I've been working on a lua mod for a while, thinking of publishing it to TPT, and I came across a big problem with lua scripts. LAG. The biggest element in question is the element COPR I made, based off of a forum suggestion I saw a few days ago. Just around 800 pixels (that's a lot less than you might think) halves my fps, and and normal amounts of the stuff brings the game down to under 10 fps. Am I doing something wrong? If not, are there any good ways to make the script more efficient? Any feedback is helpful, even if not specifically for this element. Thank you for your time and help!
Edited 8 times by CactusHamster. Last: 12th Jan 2021 -
That would certainly cause some problems! I'll fix that.
It helps a bit, but the element is still almost as laggy as ever.
-
I made a few variable changes. Version 2 has been uploaded to the same drive file now. That would be great if you could help make it less laggy.
-
I tried to make it less laggy by reducing the usage of the TPT API functions
https://pastebin.com/raw/HBqVCzCZ -
That worked so well! Thank you! Do TPT API functions make it worse? I'm new to lua scripts, and thought that it was better to use those than variables.
-
@CactusHamster (View Post)
Yes, calling any Lua api function requires it to hook back into C code, which will take a significant amount of time compared to pure Lua. Now, calling just a few functions won't have any noticeable effects, but if you are calling many, and have lots of your element on the screen, it will lag.
I see in your script you are using stuff like tpt.element('watr') a lot. Avoid this and use elem.DEFAULT_PT_WATR instead.
You also have code like:
local a = sim.partProperty(i, sim.FIELD_TMP)
local b = sim.partProperty(i, sim.FIELD_TMP)/2
You should be sure to only call sim.partProperty once, and use that to calculate a and b. Do the same in other places of your code. It is always better to create a new temporary variable to store properties that require api calls (tmp, temp, type, etc.) so that you only have to get the property once.
Minimizing api usage is also the reason many scripts use math.random. Random number generators are typically very slow, but it's actually faster than making a call to a TPT api function for every location surrounding the element. Kind of ironic, in the C code we avoid RNG like the plague, but in Lua it makes it faster.
The only comment I will make about ssccsscc's code is that elem.DEFAULT_* and other identifier constants do not require an api call. They are stored in tables on the Lua side, so there is no downside to getting a constant from the TPT api. Please always use constants wherever you can, instead of hardcoded numbers.Edited once by jacob1. Last: 13th Jan 2021
