Bit of a noob'ish question.

Solar2D General Questions/Discussion
#1

So I have a difficulty setting which is currently saved on an episode basis thanks to GG fantastic GGData library.

I have numerous modules that need to refer to this setting, so my question is:

Is it better to load in the GGData box (which contains the difficulty setting) everywhere it’s required, i.e require the GGData module and access the setting in every module that needs it.

OR

Upon initialisation load the setting once from the box and set a global variable that all additional modules can refer to?

Always followed the ‘local is better’ methodology, but the more modules I create and keep having to require GGData, access the setting, initialise a local variable, etc… makes me question whether this is actually the better approach.

Thoughts and opinions would be appreciated. [import]uid: 33275 topic_id: 35192 reply_id: 335192[/import]

#2

Don’t be afraid to use global variables.

Making a variable local means that your software “knows where a variable is stored”, so to speak, so reading it needs just one instruction: read the variable stored in this location.

Using a global variable means that your code usually does not know where a variable is stored, so reading it needs two instructions: 1) find out where this variable is stored in memory and 2) then read the variable stored in this location.

The consequence is that reading a global variable takes about twice as long as reading a local variable. Everybody will tell you to avoid global variables like the plague, but the reality is that global variables are only bad when you use them a lot and repetitively, like in a repeat loop. Reading a global variable a thousand times in stead of a local variable will mean a speed penalty. Reading it once, twice, or even three, four, five times at any given point in your code will probably be unnoticeable, so don’t worry about it.

My rule of thumb is, if it’s not in a repeat loop and it simplifies coding, use a global. Often converting a global to a local right before using it in a repeat loop fixes this issue as well.

p.s. There are times when using locals is worse than using a global var! When you just need to read a global once, converting it to local for speed purposes does the opposite. Reading a global takes two instructions, as stated above. Reading a global and converting it to a local and then reading the local takes four instructions.

I hope this makes sense! [import]uid: 70134 topic_id: 35192 reply_id: 139934[/import]

#3

Well, there’s two stances with this.

  1. Making local requires everywhere is good for performance but (technically) bad for memory because you’re loading the data from multiple points. Since memory isn’t exactly a problem for mobile devices this doesn’t bother me. I prefer this method, since you can control what files see the module.

  2. Going global when not frequently used is a good idea, not for performance per se, but simply for reducing the amount of code used. Since the Lua code is being interpreted at some point, having less of it makes it easier to maintain and somewhat faster in getting it running onscreen.

That being said if I was going the global route I still might localize the module as needed (local GGData = GGData) [import]uid: 41884 topic_id: 35192 reply_id: 139935[/import]

#4

Thanks for the heads up guys - it confirms what I was suspecting.

The whole thing with GGData for example would require me to do this in every module I need to load variables from disk:

local episode = 1  
local GGData = require("GGData")  
local box = GGData:load( "sample" )  
local difficulty = box[episode].difficulty

I need to access this variable (difficulty) for example in several different modules, so my thinking was to setup ‘box’ as a Global to avoid having to constantly require the GGData module in several different places.

Would this be appropriate?

Thanks again for the thoughts. [import]uid: 33275 topic_id: 35192 reply_id: 139943[/import]

#5

Don’t be afraid to use global variables.

Making a variable local means that your software “knows where a variable is stored”, so to speak, so reading it needs just one instruction: read the variable stored in this location.

Using a global variable means that your code usually does not know where a variable is stored, so reading it needs two instructions: 1) find out where this variable is stored in memory and 2) then read the variable stored in this location.

The consequence is that reading a global variable takes about twice as long as reading a local variable. Everybody will tell you to avoid global variables like the plague, but the reality is that global variables are only bad when you use them a lot and repetitively, like in a repeat loop. Reading a global variable a thousand times in stead of a local variable will mean a speed penalty. Reading it once, twice, or even three, four, five times at any given point in your code will probably be unnoticeable, so don’t worry about it.

My rule of thumb is, if it’s not in a repeat loop and it simplifies coding, use a global. Often converting a global to a local right before using it in a repeat loop fixes this issue as well.

p.s. There are times when using locals is worse than using a global var! When you just need to read a global once, converting it to local for speed purposes does the opposite. Reading a global takes two instructions, as stated above. Reading a global and converting it to a local and then reading the local takes four instructions.

I hope this makes sense! [import]uid: 70134 topic_id: 35192 reply_id: 139934[/import]

#6

Well, there’s two stances with this.

  1. Making local requires everywhere is good for performance but (technically) bad for memory because you’re loading the data from multiple points. Since memory isn’t exactly a problem for mobile devices this doesn’t bother me. I prefer this method, since you can control what files see the module.

  2. Going global when not frequently used is a good idea, not for performance per se, but simply for reducing the amount of code used. Since the Lua code is being interpreted at some point, having less of it makes it easier to maintain and somewhat faster in getting it running onscreen.

That being said if I was going the global route I still might localize the module as needed (local GGData = GGData) [import]uid: 41884 topic_id: 35192 reply_id: 139935[/import]

#7

Thanks for the heads up guys - it confirms what I was suspecting.

The whole thing with GGData for example would require me to do this in every module I need to load variables from disk:

local episode = 1  
local GGData = require("GGData")  
local box = GGData:load( "sample" )  
local difficulty = box[episode].difficulty

I need to access this variable (difficulty) for example in several different modules, so my thinking was to setup ‘box’ as a Global to avoid having to constantly require the GGData module in several different places.

Would this be appropriate?

Thanks again for the thoughts. [import]uid: 33275 topic_id: 35192 reply_id: 139943[/import]