optimization question about local vars

From what I’ve been reading, if you need to constantly refer to the parameter of an object ([lua]obj.x[/lua]), it’s good practice to assign that to a local var ([lua]local objX = obj.x[/lua]) and use that instead.

However, what about an item within a table? ([lua]objects[i].x[/lua])

Is it better to index the object, or index the object’s property?
for example:

[lua]local obj = objects[i]
somevar = obj.x[/lua]

or

[lua]local objX = objects[i].x
somevar = objX [/lua] [import]uid: 49447 topic_id: 17501 reply_id: 317501[/import]

In the windows world there was a similar discussion around the 2000, specially with VB called early-binding and late-binding. Have a read to understand a little more on why and which is faster.

a short answer to your question.

local foo = objects[i].x
local bar = foo

is definitely faster than

local bar = objects[i].x

though the difference might be minuscule a fraction of a second over 1000’s of iterations, but it is a performance increase never-the-less.

cheers,

?:slight_smile: [import]uid: 3826 topic_id: 17501 reply_id: 66443[/import]

I understand that, but my real question is whether I should set a local var for the item in the array, or if I should set the local var for that actual property of that item in the array.

instead of [lua]local bar = objects[i].x[/lua],

I’m trying to compare

[lua]local bar = objects[i]
somevar = bar.x[/lua]

or

[lua]local bar = objects[i]
local barX = bar.x
somevar = barX[/lua]

Of course, for my code I’m doing a LOT more than just referencing “X,” and I’m referencing them a lot more than just 1 time. [import]uid: 49447 topic_id: 17501 reply_id: 66445[/import]

depends on how many time you would access that, it offers you a bit of performance, readability and manageability.

if you had

data.longName[i].Attributes[j].itemName

now setting it as

[lua]local theItem = data.longName[i]
local theAttribute = theItem.Attributes[j]

print(theAttribute.itemName)[/lua]

that is much easier to read and manage and also provides you performance increase. So in the rest of the code you could be using theItem for comparisons instead of data.longName[i]

cheers,

?:slight_smile: [import]uid: 3826 topic_id: 17501 reply_id: 66449[/import]

here’s a snippet of what I’m actually doing. For each of these local variables, I’m accessing them more than once, some as many as 20-30 times:

[lua]local function updateSprite(ob)

local objX, objY = ob.x, ob.y
local objAction = ob.action
local objWeapon = ob.weapon
local objDirection = ob.direction
local objWidth = ob.contentWidth
local objHalfWidth = objWidth * 0.5
local objHealth, objMaxHealth = ob.health, ob.maxHealth
local objMaxXSpeed = ob.maxXSpeed
local objState = ob.state

local objDestinationX = ob.destination.x
local objReachedDestination = ob.reachedDestination

local objTarget = ob.target
local objTargetX, objTargetY = objTarget.x, objTarget.y
local objTargetWidth, objTargetHeight = objTarget.contentWidth, objTarget.contentHeight[/lua]

Just wondering if this is overkill. If it increases performance by even a 1/1000 of a second, that’s good enough for me.

p.s. thanks for your responses thus far! [import]uid: 49447 topic_id: 17501 reply_id: 66451[/import]

some might think this is an overkill, but I’d rather work with clean variables than table members in my code and definitely it will provide you with a minor performance increase.

However you also need to know that in some cases this can also be a trap for errors. The variables are the values of these items, they do not get updated automatically.
if you have
ob.sprite.x = 10
local objx = ob.sprite.x

then you issue
ob.sprite.x = 100

your objx will not automatically become 100, it will still remain 10

cheers,

?:slight_smile: [import]uid: 3826 topic_id: 17501 reply_id: 66452[/import]

yes, understood. I would have to reassign [lua]objX = ob.sprite.x[/lua] if I change the objects position.

Thanks for the feedback. I’m at a point in my project, where I’m trying to squeeze out as much performance as possible. [import]uid: 49447 topic_id: 17501 reply_id: 66455[/import]