@atilim: You think it may be related to garbage collecting? Interesting. I am not very familiar how LUA garbage collector works but i know the moment when i am calling it for full cycle. I'll play with it. Thanks for the idea.
@atilim: I new something odd was going on with these 9 versions. here is a visual test that shows clearly what is going on. Test device: IOS 5.1 Ipod 4th gen single core Retina display, resolution 960x640. This test records 16 seconds of loaded CPU fps and expand it to whole width of the display /2pix per frame/. Sorry @atilim i tried to do it pixel per frame but shape function do odd things after 900 sub-paths. The problem is in spikes above the average level. In old version they occur once per 7-8 sec and almost every second for 9.x versions. I got no idea why e.deltaTime returns these strange values so the chart goes sky high but it happens rarely in the old version and quite often in all 9.x versions and it is visible on screen when you have slow moving objects. I have to mention that there is no difference between 9.2 and 9.5, both behave same. I hope this can help to investigate what happens.
it will be interesting to see this on more powerful devices. there is "load" variable in project to adjust load according to device and maybe we will have clear view about multi-core hardware. Oh and collectgarbage("stop") didn't change things in my project.
I have some tests on 09.5 with iPod touch 4th gen.
When you don't push the limits of the device (load = 10, 200 movie clips), you don't get any spikes. Here NSTimer and CADisplayLink gives similar results. (CADisplayLink seems better (less noisy) because it's synchronized to the refresh rate of the display).
When you push the limits of the device (load = 30, 600 movie clips) and try to get fps lower than 30fps, you start to get spikes. Here NSTimer gives a little bit better results than CADisplayLink. Because I think CADisplayLink tries to synchronize to 30fps, but it cannot and therefore calls ENTER_FRAME with (very) small time intervals.
But I'll investigate more why 2.2.2 gives slower but more stable results.
I forgot to mention that the very first value of e.deltaTime is not valid and it is the reason i put the first "if..then" check in the code. But lower two screens /loaded state/ clearly reproduce the difference between 2.2.2 and 9.x In loaded state NSTimer is less spiky though lower frame rate and looking on CADisplayLink seems they have equal amount of spikes above the average fps no mater the load is. Are you sure in upper left image you don't have spikes continue above the screen? Probably we have to print the e.deltaTime values to be sure.
@atilim: Now it all makes sense. In 9.x version spikes are no visible when load is less and device is running at desired frame rate /as you said/ As soon it drops below the set frame rate /30 in my case/ spikes start to appear and irregularities in enterFrame interval also. The bigger the load and lower the fps the more are the spikes. And because my project is box2D driven with box2D update and all applyImpulse() and applyForce() movement functions called in enterFrame event this is the reason of the jerky movements. If means for me that i have to keep the fps at 30 all the time no mater what for the weakest device /Ipod 4th gen/ or to address more powerful devices only. This issue is not visible on Iphone 4GS with dual core A5 chip. I have to admit the fact that the game is absolutely playable with fps drop down to 20-21 fps with regular intervals and very annoying with 27 fps irregular intervals. I have to make a decision... :-? And here is the latest test. It perfectly illustrates the issue. Look at the motion of the image on both versions and average frame rate. I removed graphic load and left only pure LUA load so it became very interesting.
Comments
When you don't push the limits of the device (load = 10, 200 movie clips), you don't get any spikes. Here NSTimer and CADisplayLink gives similar results. (CADisplayLink seems better (less noisy) because it's synchronized to the refresh rate of the display).
When you push the limits of the device (load = 30, 600 movie clips) and try to get fps lower than 30fps, you start to get spikes. Here NSTimer gives a little bit better results than CADisplayLink. Because I think CADisplayLink tries to synchronize to 30fps, but it cannot and therefore calls ENTER_FRAME with (very) small time intervals.
But I'll investigate more why 2.2.2 gives slower but more stable results.