Any evidence that After and For timers are actually slow?

ORBZ

I know there is a lot of people who say that Timers are the cause of a lot of slowdown in GS. That was definitly the case in earlier builds, and obviously a very high resolution "Every" timer is going to cause slowdown. But what about For and After timers without turning on "Run To Completion?"

I have not noticed any difference in game speed between using a rule that says: self.time > duration VS a timer that just says: After duration.

Now, I don't know what GS does in the background when you create a For or After timer. But it does seem like it doesn't need to be very complex. If any GS devs would like to settle this issue once and for all and let us know definitively how Timers work on a technical level that would be really great! Are they events? Are they system hooks? Is it just an IF statement that gets evaluated every frame? What are they really?

So my question to you is this: Has anyone done any in depth studies into Timers and specifically For and After timers WITHOUT using run to completion. I would like to see your data please, not just your opinion.

I don't see the slowdown which is why I would like to know if it's even there, they seem to work fine to me.

If there is no measurable difference then using Timers is far simpler to code since you don't need to create timestamp variables.

Thanks for your input

master200012

Here it is! This is a comment the author made himself/herself...

I've been doing a few tests to show the inherit flaws of GS timers vs time variables and to show the differences in operation visually. I created a stress test project that I believe shows the differences quite well. It also demonstrates how to use mod timers for efficient animation. You will notice that the animations tagged as "math" do not jitter as much when stress is placed on the application and they maintain an even iteration time. The timer based animation does NOT maintain an even iteration time, you will see these animations slowly move in and out of sync with the others. Even timer based animation is better than the default animate behaviour, which is also demonstrated in this app. It looks something like this:



The most troubling part of this application is the two timers shown at the bottom of the screen. The top number (in light blue) represents the number of seconds that has gone by since application start using game.time, the second number (in purple/pink) shows time gone by since application start using a timer that updates every 0.05 seconds. You can check the code if you like, I'm not doing anything to simulate a loss of time. In fact, I update the time on game initialization to game.time to make the test more fair. As the application runs, these numbers move further and further out of sync. When you place load on the project (using the stress test button) the issue is further intensified.

On my mac the times do not move as far out of sync, its a new macbook pro with an i7 and a bunch of ram, but on device (iPhone 4) the issue is very obvious even with a full adhoc build. I'm sure is even worse on a 3gs. Truth be told, the inaccuracy of timers is even worse than I had originally thought. I would really like to hear from the GS development team as far as why this happens and if it's something that can be fixed on native GS timers. It's bad enough that these timers are slow, but they should at least be accurate. If anyone wants to try the project themselves I would be really interested to hear the results on other devices as well, download it here: http://www.gamefront.com/files/21823560/stresstest.gameproj.zip



Me again! Now, I actually haven't downloaded this project, but I believe others have, so it should be safe.

Hope this helps!

master200012

Well, I've just conducted a small experiment to see the difference between the new optimal techniques and standard timers. Turns out the accuracy of "for" and "after" timers is off by a variation of 0.02 seconds in the worst case. While this may seem rather minuscule, in some people's projects this could be critical.
Moreover, this inaccuracy can hamper performance, but I've yet to see a huge change in performance overall.

Hope this helps!

ORBZ

@master200012

Could you elaborate on your techniques and results please.

master200012

Hold on, I'll post a video shortly...having screencast issues right now... :P

Rob2

I have found GS doesn't really 'do' less than a 1/30th of a second.... some may find that significant

master200012

Actually, this is the first time I've seen it dead on five, but I've re-run it 3 times to show you the accuracy...

ORBZ

@master20012

Could you explain what this video is testing? and how that relates to framerate?

master200012

Oh, my bad! So, on the left, i used a timer. For 5 seconds, I constrained an attribute in the actor (called it timeStamp) to self.Time and had the actor display the text "timeStamp."

On the left, I used the same thing, except instead of using a timer I used a rule. When self.time is < than 5, *do the same thing as the other actor*. Thus this tests the accuracy.

Similarly, I'll just post another video in a moment...

Sorry for the delay! :P

--EDIT: Turns out for something this small, it doesn't make a visible dent. But I'll post anyway--

Rob2

@master200012 GS timers under about .033 do not get any 'shorter'. Timers are incapable of measuring times under a 1/30th of a second. Half the maximum framerate/speed of the main engine loop

master200012

So, yeah... This was from a previous test of my experiment actually, since my screencaster really wrecks the whole thing... :P

Hope this helps.

master200012

Oh sorry, Rob2! I never refreshed the page, so when I did, first I saw ORBZ request but somehow missed yours!

Now that I think about it, you are right... X_X

ORBZ

I see you updated your video. So what is the new one showing with the FPS and how did you construct the test?

Also, you can't use DisplayText when measureing framerate because on a device DisplayText KILLS framerate.

master200012

@ORBZ -- I hope! :P

Well, judging by your knowledge on this topic, I assume you've read the post about Timer optimization...personally, I also trust the people that have commented on that post.

Furthermore, I'm pretty sure I saw a stress test post in the comments somewhere....

Also, people claimed to have it done, and if tons of people agree and praise it (this includes some well-known figures ), then I'm sure its of critical importance...

I hope this helps!

master200012

Oh, wait, you changed your post!

Well, without putting in a full game to test it all, it is hard to say...

That said, I'm gonna have to hand this over to someone more experienced...sorry!

Hope I helped! :P

EDIT: --You changed your post once more!!! :P--

ORBZ

Ya, I have seen that thread. That's what made me start wondering if it was true or not because I don't see a performance difference. I see a performance difference in relation to Every timers, but I do not see a performance difference with After and For timers.

I am only talking about in my game. I haven't created any sandboxed tests which is why I was hoping someone else had made a test so that I didn't have to.

I do appreciate your input. Is there a specific stress test that you've seen? I can't find one.

ORBZ

@master200012

Thanks! I think that's what I was looking for.

ORBZ

Animate Behavior is really borked, what the hell GS, fix that!

Rob2

@ORBZ a Tynan classic that you may have missed

http://forums.gamesalad.com/discussion/40335/gss-animate-is-screwed/p1

ORBZ

Ahh yes, thanks @Rob2