Speed of reading from global and settings

[darkfrei]

What needs less time for read the values?

Code: Select all

local value = global.value

or

Code: Select all

local value = settings.global['value_name'].value

?

[PyroFire]

When you're at the point where you're asking about micro-optimizations, you've lost sight of the bigger picture and probably don't need to change anything.
Unless you're looking these up a hundred thousand times per tick (100,000), odds are that no one will notice it running 0.00000000000000000000001s faster for either case.

Sounds like a case of premature optimization

But to actually answer your question, generally the longer lookup chain will take longer, but can also be affected by the size of the tables you're using.
So the settings one is "slower" (by about 0.0000000000000000000000000000000000001%) than the global one.

But does that tiny fraction really matter that much for your program?

[DaveMcW]

According to Bilka (on the wiki), settings is MUCH slower.

You should cache the settings table inside the event you use it in. Accessing it is relatively expensive (about as expensive as accessing game.*prototypes[...]), so when accessing it mutliple times within the same event, you should set a local variable to it (within the event) to improve performance.

[darkfrei]

Do I need to set all settings to the global?

For example
https://lua-api.factorio.com/latest/eve ... ng_changed

Code: Select all

function on_runtime_mod_setting_changed (event)
  local setting_name = event.setting
  global.mod_settings[setting_name] = settings.global[setting_name]
end

[PyroFire]

Do I need to set all settings to the global?

I would discourage putting anything extra in global that you don't need to for the sole reason that it increases save file sizes and can make saving take longer.

Use a local instead, e.g. local localsettings={}
function on_settings_changed()
localsettings[whatever]=newvalue
end

Be sure to put that in on_load and on_init.

Personally though i don't see this as reason enough to restructure how i read settings, with the exception of referencing a single setting several times in a tick function.

[Bilka]

According to Bilka (on the wiki), settings is MUCH slower.

It says "relatively expensive" and gives advice that is good for any long table access path. That's not the same as "MUCH slower".

[Honktown]

I can tell you from a tiny experience with this, how you handle your data will matter much more than access times.

For my "prototype" version of my delayed regeneration mod, I refer to global settings, and accessed two or three-deep properties multiple times in a single tick (it was not every tick).

1. As soon as I knew I didn't need to track an entity, I stopped tracking it or didn't start.
2. I stored information as simply as possible.
3. I compared times to other mods . A mod that I like to use had running times that were 10-100x my mod, constantly. That mod let me make biter spawners, so I had lots of biters that needed regeneration every second (I only healed once per second), both of which gave me a good idea of how I could expect my performance to be.

I updated and made small optimizations:
If I needed a value I should have needed to calculate once, I did that and stored it instead of calculating every time.

I didn't have to define multiple functions, but if you have a ton of run-time checking for behavior, it may be more optimal to just define the function you're running based on something, instead of doing all the checking in a single function.