Is there a way to benchmark this?

[dmglakewood]

I’m looking to move about 25 objects and I was wondering if it’s better performance to use an enterframe or transitions. I would think transitions would consume a lot more memory but not positive. I’m using an enterframe now and I’m noticing some lag. 

[dmglakewood]

I’ve tried using memory tools but I found that the memory tools themselves consume memory so the memory continues to climb and it’s hard to get an idea on actual memory usage. 

[roaminggamer]

Are you worried about memory usage or frame-lag?  I’m seeing two parts to your question.

1. Memory - In either case, memory usage is negligible.

2. Lag - In either case, 25 objects is so few the difference in performance is not measurable.

Are you going to be growing beyond 25?  I wouldn’t worry till I hit 1000s (assuming the movement is linear and not using sin(), cos(), etc. calculations.)

Not satisfied with this answer?  Share you’re code and I’ll give you measurements.

[dmglakewood]

@roaminggamer

Are you worried about memory usage or frame-lag?  I’m seeing two parts to your question.

1. Memory - In either case, memory usage is negligible.

2. Lag - In either case, 25 objects is so few the difference in performance is not measurable.

Are you going to be growing beyond 25?  I wouldn’t worry till I hit 1000s (assuming the movement is linear and not using sin(), cos(), etc. calculations.)

Not satisfied with this answer?  Share you’re code and I’ll give you measurements.

I’m more worried about lag. While 25 objects is very few it seems to lag while other things are going on. For example if I make a background call to my server the objects will lag for example. I figured if I could optimize the performance of moving the objects it would remove the lag, but now I’m thinking the lag might be caused by something else? The code that is running is really quite minimal. It’s simply something like so:
 

function gameLoop(event) for i=1,25 do obj[i].y = obj[i].y + speed if(obj[i].y \> bottom) then obj[i]:removeSelf() obj[i] = nil obj[i] = display.newImage("image.png") obj[i].y = start end end end Runtime:addEventListener("enterFrame", gameLoop)

That’s a little dumbed down but it’s not a whole lot more complex then that.

[roaminggamer]

The lag is caused by the asynchronous handling of the network event.  The event comes in and takes high if not instant priority.  Everything stops while the data is sucked off the web and stored.  

This will be especially noticeable when loading remote images for use as a fill image in an existing rectangle that is in the middle of a transition. (I’m constantly battling that in this app: https://itunes.apple.com/us/app/menume/id700326215?mt=8))

Regarding your code.  If you can get away with re-using the images, I’d create them once and move them back to the top.  This will alleviate the creation penalty.

Regardless, this should not lag for reasonably sized fill textures.

I said I’d measure your code,  you could do this:

-- Show time from frame to frame (NOT an FPS counter) local lastTime = system.getTimer() local curTime local timeLabel = display.newText( 0, 100, 100, native.systemFont, 40 ) timeLabel.enterFrame = timeLabel.toFront Runtime:addEventListener( "enterFrame", timeLabel ) -- keep me on top function gameLoop(event) for i=1,25 do obj[i].y = obj[i].y + speed if(obj[i].y \> bottom) then obj[i]:removeSelf() obj[i] = nil obj[i] = display.newImage("image.png") obj[i].y = start end end curTime = system.getTimer() timeLabel.text = curTime - lastTime lastTime = curTime end Runtime:addEventListener("enterFrame", gameLoop)

There are many better ways to do this, but this is straight forward.

[dmglakewood]

@roaminggamer

The lag is caused by the asynchronous handling of the network event.  The event comes in and takes high if not instant priority.  Everything stops while the data is sucked off the web and stored.  

This will be especially noticeable when loading remote images for use as a fill image in an existing rectangle that is in the middle of a transition. (I’m constantly battling that in this app: https://itunes.apple.com/us/app/menume/id700326215?mt=8))

Regarding your code.  If you can get away with re-using the images, I’d create them once and move them back to the top.  This will alleviate the creation penalty.

Regardless, this should not lag for reasonably sized fill textures.

I said I’d measure your code,  you could do this:

-- Show time from frame to frame (NOT an FPS counter) local lastTime = system.getTimer() local curTime local timeLabel = display.newText( 0, 100, 100, native.systemFont, 40 ) timeLabel.enterFrame = timeLabel.toFront Runtime:addEventListener( "enterFrame", timeLabel ) -- keep me on top function gameLoop(event) for i=1,25 do obj[i].y = obj[i].y + speed if(obj[i].y \> bottom) then obj[i]:removeSelf() obj[i] = nil obj[i] = display.newImage("image.png") obj[i].y = start end end curTime = system.getTimer() timeLabel.text = curTime - lastTime lastTime = curTime end Runtime:addEventListener("enterFrame", gameLoop)

There are many better ways to do this, but this is straight forward.

Cool I will try to make the calls a better times. I’m actually using delta time in my loop to make it run a little smoother but the objects get a little choppy when the FPS drop down. It’s better then not using it but still not perfect. 

[dmglakewood]

I’ve tried using memory tools but I found that the memory tools themselves consume memory so the memory continues to climb and it’s hard to get an idea on actual memory usage. 

[roaminggamer]

Are you worried about memory usage or frame-lag?  I’m seeing two parts to your question.

1. Memory - In either case, memory usage is negligible.

2. Lag - In either case, 25 objects is so few the difference in performance is not measurable.

Are you going to be growing beyond 25?  I wouldn’t worry till I hit 1000s (assuming the movement is linear and not using sin(), cos(), etc. calculations.)

Not satisfied with this answer?  Share you’re code and I’ll give you measurements.

[dmglakewood]

@roaminggamer

Are you worried about memory usage or frame-lag?  I’m seeing two parts to your question.

1. Memory - In either case, memory usage is negligible.

2. Lag - In either case, 25 objects is so few the difference in performance is not measurable.

Are you going to be growing beyond 25?  I wouldn’t worry till I hit 1000s (assuming the movement is linear and not using sin(), cos(), etc. calculations.)

Not satisfied with this answer?  Share you’re code and I’ll give you measurements.

I’m more worried about lag. While 25 objects is very few it seems to lag while other things are going on. For example if I make a background call to my server the objects will lag for example. I figured if I could optimize the performance of moving the objects it would remove the lag, but now I’m thinking the lag might be caused by something else? The code that is running is really quite minimal. It’s simply something like so:
 

function gameLoop(event) for i=1,25 do obj[i].y = obj[i].y + speed if(obj[i].y \> bottom) then obj[i]:removeSelf() obj[i] = nil obj[i] = display.newImage("image.png") obj[i].y = start end end end Runtime:addEventListener("enterFrame", gameLoop)

That’s a little dumbed down but it’s not a whole lot more complex then that.

[roaminggamer]

The lag is caused by the asynchronous handling of the network event.  The event comes in and takes high if not instant priority.  Everything stops while the data is sucked off the web and stored.  

This will be especially noticeable when loading remote images for use as a fill image in an existing rectangle that is in the middle of a transition. (I’m constantly battling that in this app: https://itunes.apple.com/us/app/menume/id700326215?mt=8))

Regarding your code.  If you can get away with re-using the images, I’d create them once and move them back to the top.  This will alleviate the creation penalty.

Regardless, this should not lag for reasonably sized fill textures.

I said I’d measure your code,  you could do this:

-- Show time from frame to frame (NOT an FPS counter) local lastTime = system.getTimer() local curTime local timeLabel = display.newText( 0, 100, 100, native.systemFont, 40 ) timeLabel.enterFrame = timeLabel.toFront Runtime:addEventListener( "enterFrame", timeLabel ) -- keep me on top function gameLoop(event) for i=1,25 do obj[i].y = obj[i].y + speed if(obj[i].y \> bottom) then obj[i]:removeSelf() obj[i] = nil obj[i] = display.newImage("image.png") obj[i].y = start end end curTime = system.getTimer() timeLabel.text = curTime - lastTime lastTime = curTime end Runtime:addEventListener("enterFrame", gameLoop)

There are many better ways to do this, but this is straight forward.

[dmglakewood]

@roaminggamer

The lag is caused by the asynchronous handling of the network event.  The event comes in and takes high if not instant priority.  Everything stops while the data is sucked off the web and stored.  

This will be especially noticeable when loading remote images for use as a fill image in an existing rectangle that is in the middle of a transition. (I’m constantly battling that in this app: https://itunes.apple.com/us/app/menume/id700326215?mt=8))

Regarding your code.  If you can get away with re-using the images, I’d create them once and move them back to the top.  This will alleviate the creation penalty.

Regardless, this should not lag for reasonably sized fill textures.

I said I’d measure your code,  you could do this:

-- Show time from frame to frame (NOT an FPS counter) local lastTime = system.getTimer() local curTime local timeLabel = display.newText( 0, 100, 100, native.systemFont, 40 ) timeLabel.enterFrame = timeLabel.toFront Runtime:addEventListener( "enterFrame", timeLabel ) -- keep me on top function gameLoop(event) for i=1,25 do obj[i].y = obj[i].y + speed if(obj[i].y \> bottom) then obj[i]:removeSelf() obj[i] = nil obj[i] = display.newImage("image.png") obj[i].y = start end end curTime = system.getTimer() timeLabel.text = curTime - lastTime lastTime = curTime end Runtime:addEventListener("enterFrame", gameLoop)

There are many better ways to do this, but this is straight forward.

Cool I will try to make the calls a better times. I’m actually using delta time in my loop to make it run a little smoother but the objects get a little choppy when the FPS drop down. It’s better then not using it but still not perfect.