Calls across modules - effect on performance

Solar2D General Questions/Discussion
#1

Suppose I create a file called properties.lua with the following content:

local M = {} M.myVariable = 10 M.floor = math.floor return M

and then access the variables from module X by requiring the properties module:

local properties = require( "properties" )

Will it make any difference from a performance perspective if I do the above or declare the two variables in module X instead? In other words: will “cross module calls” affect performance negatively compared to calls within the same module?

#2

Hello,

When you load your module using require(), the variable “properties” is inserted into the global “_LOADED” namespace:

\_LOADED["properties"] = { myVariable = 10, floor = math.floor }

This means that requiring() “properties” twice will only incur one load, since it already has a key in _LOADED (see http://www.lua.org/pil/8.1.html). Moreover, you’re assigning the value _LOADED[“properties”] to the local variable “properties” in your code, so there is no real cost after its loaded via require().

So you should make it a point to encapsulate logic in a module and to reuse it inside other modules, as having two variables in the same module for sake of performance would give you no performance benefits.

I hope that helped

Albert

#3

discrete locals created in the current module would have a slight performance advantage. (because you won’t have to index the table “properties” to find the things inside it)  if it’s something you’d be using 1000 times in a tight critical loop, then maybe that matters, but often not.

the primary advantage of your “properties” module will be sharing things like “properties.myVariable” across whatever other modules happen to require it.  (as per Albert, it’s only actually loaded once, so all modules share the same instance)  so if it needs to be widely/easily shared, then that should far outweigh any performance concerns.

your “properties.floor” appears to be an attempt to alias math.floor to improve indexing speed.  but you’ll still have to index “properties” to get at its “floor”, so that’s not much gain.  if you need this speed boost, then this is where you’d want a module-local, fe:  local math_floor = math.floor

#4

Thanks guys!

The only reason I have the properties module is to have variables that I can reach from every other module (instead of creating global variables, as explained in the tutorial “Goodbye Globals”. The properties module is required among the first things that happen at app startup, which means that this step (including indexing?) is already taken care of before the actual gameplay begins.

From your answers, I gather that the performance loss is negligible and that this is the preferred way of creating variables (including libraries like math) that must be accessed from everywhere. Right?

#5

Hello again,

Yes, you’re assuming correctly. My game has over 200 modules/classes and is running at 60fps on most devices. Good luck!

Albert

#6

Thanks everyone!

#7

Hello,

When you load your module using require(), the variable “properties” is inserted into the global “_LOADED” namespace:

\_LOADED["properties"] = { myVariable = 10, floor = math.floor }

This means that requiring() “properties” twice will only incur one load, since it already has a key in _LOADED (see http://www.lua.org/pil/8.1.html). Moreover, you’re assigning the value _LOADED[“properties”] to the local variable “properties” in your code, so there is no real cost after its loaded via require().

So you should make it a point to encapsulate logic in a module and to reuse it inside other modules, as having two variables in the same module for sake of performance would give you no performance benefits.

I hope that helped

Albert

#8

discrete locals created in the current module would have a slight performance advantage. (because you won’t have to index the table “properties” to find the things inside it)  if it’s something you’d be using 1000 times in a tight critical loop, then maybe that matters, but often not.

the primary advantage of your “properties” module will be sharing things like “properties.myVariable” across whatever other modules happen to require it.  (as per Albert, it’s only actually loaded once, so all modules share the same instance)  so if it needs to be widely/easily shared, then that should far outweigh any performance concerns.

your “properties.floor” appears to be an attempt to alias math.floor to improve indexing speed.  but you’ll still have to index “properties” to get at its “floor”, so that’s not much gain.  if you need this speed boost, then this is where you’d want a module-local, fe:  local math_floor = math.floor

#9

Thanks guys!

The only reason I have the properties module is to have variables that I can reach from every other module (instead of creating global variables, as explained in the tutorial “Goodbye Globals”. The properties module is required among the first things that happen at app startup, which means that this step (including indexing?) is already taken care of before the actual gameplay begins.

From your answers, I gather that the performance loss is negligible and that this is the preferred way of creating variables (including libraries like math) that must be accessed from everywhere. Right?

#10

Hello again,

Yes, you’re assuming correctly. My game has over 200 modules/classes and is running at 60fps on most devices. Good luck!

Albert

#11

Thanks everyone!