a newbie question

MoKaLux · December 2019

I need your help please. Is this code correct?

local textfield = nil
-- texfield 1
textfield = TextField.new(nil, "my first text")
self:addChild(textfield)
-- texfield 2
textfield = TextField.new(nil, "my second text")
self:addChild(textfield)

Will both textfields use the same local variable?
Is it good practice to do this?
Thank you.

PaulH · December 2019

If you don't plan to access the textfields after you've added them to a sprite, generally I don't think that's harmful. Just be aware of what variables have been reused. Suppose you wrote:

function add_text_to_sprite(sprite)
local textfield1 = TextField.new(...)
sprite:addChild(textfield1)
local textfield2 = TextField.new(...)
sprite:addChild(textfield2)
end
add_text_to_sprite(my_sprite)

Since the two text fields are local variables, local to the function, the variables are gone after the function returns, but the text fields remain as children of my_sprite. There's no harm in doing the same with a single variable:

function add_text_to_sprite(sprite)
local textfield = TextField.new(...)
sprite:addChild(textfield)
textfield = TextField.new(...)
sprite:addChild(textfield)
end
add_text_to_sprite(my_sprite)

That has exactly the same effect. The more important factor is to use a variable that's local to the scope where you need it.

In your example, when you create the second TextField, you're reusing the variable you created for the first one. The only way you'd be able to access the first one again would be to get the child of the Sprite you added it to. Suppose later you wanted to change the text in the first one. If you wrote:

textfield:setText("new text")

that would change the text of the second one created. To change the text in the first one you'd have to do something like:

textfield = self:getChildAt(1)
textfield:setText("new text")

Which only works if you're keeping track of the number of children in the sprite where you added it, so you know which child is the TextField you want to change.

So I'd say feel free to reuse variable names (there can even be memory advantages to doing so) but only when you know you won't need to access whatever it was the variable originally referred to again.

Paul

MoKaLux · December 2019

PaulH said:
If you don't plan to access the textfields after you've added them to a sprite, generally I don't think that's harmful.

I don't need to change the text so that's cool. I am using it in a for loop.

PaulH said:
So I'd say feel free to reuse variable names (there can even be memory advantages to doing so)

That's exactly what I am after: optimisation (even if it's not a lot). I wanted to make sure that the second textfield was using the same local variable.

Thank you very much for your detailed answer, very much appreciated.

Apollo14 · December 2019

btw 'nil' is not necessary when you declare locals

local textfield = nil --not necessary

you can declare it just like that:

local textfield

rrraptor · December 2019

I did a quick tests to show that if you store references to objects in tables, then you have to clear those references after the object is destroyed. But its not always the case

In all tests I'm creating a grid of textfileds.

test1: create textfiled, add it to scene, add it to local table (t).
test2: create textfiled, add it to scene
test3: create textfiled, add it to scene, add it to global table (globalTable).
test4: create textfiled, add it to scene, add it to scene table (scene.t).

Tweak CLEAR_GLOBAL_TABLE and DELETE_SCENE "variables" to see how they affect memory usage

CLEAR_GLOBAL_TABLE @ true
DELETE_SCENE @ true
 
NUMBER_OF_TESTS @ 4
EPSILON @ 0.01
 
SCALE @ 4
OFFSET @ 10
 
local scene
local globalTable
local initMemUsage
 
function getMem(msg, printLine, symbol)
	if (printLine) then 
		symbol = symbol or "-"
		print(string.rep(symbol, 35))
	end
	-- force gc to collect garbage
	for i = 1, 4 do collectgarbage() end
	-- convert kbytes to megabytes 
	local mb = collectgarbage("count")/1024
	print(msg, string.format("Memory: %f mb", mb))
	return mb
end
 
function runTest(n)
	scene = Sprite.new()
	stage:addChild(scene)
 
	local memory = getMem(string.format("Initializing test %i", n), true)
	_G["test"..n]() -- call test function (test1, test2, ...)
 
	local diff = (collectgarbage("count")/1024) - memory -- calculate memory usage used by test
	print(string.format("Test %i - %f mb", n, diff))
	memory = getMem(string.format("	Before cleaning test %i",n)) -- print memory usage before cleaning up everything
	local approx = memory - diff
	print(string.format("	Approximate memory usage after cleaning up: %f", approx)) 
	scene:removeFromParent()
	if (DELETE_SCENE) then 
		scene = nil
	end
	local cleaned = getMem(string.format("	Cleaning after test %i", n))
 
	if (not(cleaned>= approx-EPSILON and cleaned<=approx+EPSILON)) then 
		print("!!! Posible memory leak!!!")
	end
 
	-- if next text exists, run it
	if (n+1 <= NUMBER_OF_TESTS) then 
		runTest(n+1)
	-- otherwise output some info
	else
		if (CLEAR_GLOBAL_TABLE) then 
			globalTable = nil
		end
		local finishedMemUsage = getMem("All tests finished.", true)
		if (not(finishedMemUsage >= initMemUsage-EPSILON and finishedMemUsage <= initMemUsage+EPSILON)) then 
			print("!!!Memory leak!!!")
		end
 
		print(string.format("scene is %s deleted", type(scene) == "nil" and "" or "not"))
		print(string.format("globalTable is %s deleted", globalTable == nil and "" or "not"))
	end
end
 
function test1()
	local t = {}
	for y = 1, 11 do 
		t[y] = {}
		for x = 1, 20 do 
			local tf = TextField.new(nil, tostring(math.random(9)), "|")
			tf:setScale(SCALE)
			tf:setPosition(x * (30 + OFFSET), y * (30 + OFFSET))
			scene:addChild(tf)
			t[y][x] = tf
		end
	end
end
 
function test2()
	for y = 1, 11 do 
		for x = 1, 20 do 
			local tf = TextField.new(nil, tostring(math.random(9)), "|")
			tf:setScale(SCALE)
			tf:setPosition(x * (30 + OFFSET), y * (30 + OFFSET))
			scene:addChild(tf)
		end
	end
end
 
function test3()
	globalTable = {}
	for y = 1, 11 do 
		globalTable[y] = {}
		for x = 1, 20 do 
			local tf = TextField.new(nil, tostring(math.random(9)), "|")
			tf:setScale(SCALE)
			tf:setPosition(x * (30 + OFFSET), y * (30 + OFFSET))
			scene:addChild(tf)
			globalTable[y][x] = tf
		end
	end
end
 
function test4()
	scene.t = {}
	for y = 1, 11 do 
		scene.t[y] = {}
		for x = 1, 20 do 
			local tf = TextField.new(nil, tostring(math.random(9)), "|")
			tf:setScale(SCALE)
			tf:setPosition(x * (30 + OFFSET), y * (30 + OFFSET))
			scene:addChild(tf)
			scene.t[y][x] = tf
		end
	end
end
 
print(string.format([[Settings:
	CLEAR_GLOBAL_TABLE - %s
	DELETE_SCENE - %s
]], tostring(CLEAR_GLOBAL_TABLE), tostring(DELETE_SCENE)))
initMemUsage = getMem("Initial state.", true)
runTest(1)

MoKaLux · December 2019

@rrraptor this was supposed to be a noob question

I am going to give it a try and see what I've got. Thank you for your help.

rrraptor · December 2019

@MoKaLux just keep in mind that if you have refence to object and when you dont need that object you need to remove reference AND the object itself (like sprite:removeFromParent() myRefernceValue = nil)

But I guess, if you are using SceneManager, then it should not be a problem.

Apollo14 · December 2019

and I've noticed that sometimes objects never get garbagecollected automatically, even if they're already nil and removed from parents

but after manual 'collectgarbage()' call they get collected

rrraptor · December 2019

Apollo14 said:
and I've noticed that sometimes objects never get garbagecollected automatically, even if they're already nil and removed from parents

but after manual 'collectgarbage()' call they get collected

Lua uses a garbage collector that runs from time to time to collect dead objects when they are no longer accessible from the Lua program.

So it won't be collected right away (unless you will force gc to collect).

oleg · December 2019

Apollo14 said:
and I've noticed that sometimes objects never get garbagecollected automatically, even if they're already nil and removed from parents

but after manual 'collectgarbage()' call they get collected

All object references must be deleted so that they are automatically deleted.

If you delete the link to the parent sprite, you need to collect garbage twice to collect his children

SinisterSoft · December 2019

I do this at the end of my main.lua

collectgarbage("setstepmul",1000)
collectgarbage()

And this on my main enter frame event:

collectgarbage("step")
--print(collectgarbage("count")*1024)

This means the collection is done regularly but not too much at once. You should tweak the 1000 for your games but it's a good starting point. The count give you an indication of which direction you should be going in.

PaulH · December 2019

I used to call collectgarbage() fairly often in my code. Now I usually on call it if I'm changing between scenes, something that doesn't happen in real time, and involves getting rid of a lot of Sprites. It might be my imagination, but automatic garbage collection seems to be working better than it once did, or perhaps I've gotten better at using local variables, so I don't accidentally leave references around for things that are no longer needed.

In the 3D asteroid sample, I'm never calling collectgarbage(). New asteroids are created every few frames, and each gets added to a sprite in the scene. No variable is kept that references it. When the asteroid moves out of sight behind the camera, or gets destroyed, I remove it from its parent. When the ship is destroyed it creates 500 meshes for fragments of the ship, and each of those gets removed from the scene after a certain number of frames. Each asteroid destroyed creates 50 fragments that behave the same way. In theory, the memory for all those asteroids and fragments could get freed up anytime after they've been removed from the scene.

I was curious to see if automatic garbage collection would keep up with all the asteroids and fragments that have been removed from the scene, or if the memory usage would continually climb. It seems the automatic collection handles this just fine. I can leave the game running for an extended period of time and the memory usage stays within the usual range.

Still, calling collectgarbage() periodically is probably a wise practice in general, especially using the method @SinisterSoft suggested.

keszegh · January 2020

@SinisterSoft , no need to test, i think he failed the turing test basically in each of his posts.

Howdy, Stranger!

Categories

In this Discussion

Top Posters

a newbie question

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

a newbie question

Comments