Millisecs() strategyMonkey Programming Forums/Monkey Programming/Millisecs() strategy
| ok, so it seems Millisecs() is very expensive and I'm using it way too much. I'm using it for time based animation and other changes. I'm now thinking of moving to update frames instead but I will still need accurate Millisecs for some parts. has anybody run into this? what are you guys using for timing?|
on side note.... xcode's debugger and profiler (Instruments) are f'in awesome!
| Why do you need a time value that is more precise than your frame update? |
| maybe I don't... that's what I'm going to test tomorrow when I get back. I didn't anticipate it would be so expensive to call so I built a lot around it. I was ignorant as I've never taken that approach before. Normally I just use a tween value calculated once per frame with my own timing method on PC and Macs and I have to say is super smooth, check out rocks :) I was just thinking it would be better to not skip over 16ms for everything that I tween. also since in monkey I'm not is complete control of the timing method, I thought I needed to be more accurate.... I'm thinking now that was probably a poor assumption?|
what do you do? thinking about it now, I will probably key all the animation on the current frame number and call Millisecs just in render to get a tween value. that should work... I wish I wasn't going drinking tonight so I could try this now! :D
| I just have global time values that I set once per update loop. Each update/render is a frozen point in time so there's no value in continually getting the "real" time during those time slices. In fact doing so could cause synchronisation problems as time gets smeared across your game update.|
Note that when I say "once per update loop" I mean whatever update loops you have in your game that need time information, not necessarily the mojo update loop. For example, my current project maintains separate concepts of user time and game world time so there's one time value for each but neither are updated more than once per pass through the relevant loop.
Class Game Extends App Global Time:Int Method OnUpdate:Void() Time = Millisecs() LogicUpdate() End End
Then access it with Game.Time in your code. That is how I solved it.
so it seems Millisecs() is very expensive
How expensive is it?
time = Millisecs()
Identifier not found. :)
| Oh no ... ^^|
Updated post to correct version.
How expensive is it?
Too expensive if you are using it around 200+ times per second.
| Seems odd that it would be so expensive. Surely every OS has some sort of counter that tracks time and just needs to be read? |
| I'm going to have to look into this. |
| Yeah this surprises me that it would apparently be so slow... |
| Calling it once per frame should be enough. |
Calling it once per frame should be enough.Enough for any purpose? Or enough to slow it down?
How expensive is it?
Not sure what to compare it to but my testing seems to show that's it's 3+ times slower than Rnd. On my iPhone 4 though it's 10 times slower with the million executions coming out at ~2500ms and the Rnd coming out at ~250ms. the xcode profiler confirms these timings.
And just to be clear, it's not monkey, it's mach_absolute_time. my test were done with monkey non debug build on pc-html, pc-glfw, mac-iphone 4, mac-glfw. the iphone test for Instruments was a "profile" build.
the pc-glfw was about 30 times slower but the million runs came in at 33ms so pretty insignificant which is why I didn't notice this until load testing on other targets.
| A million executions in 2500 ms is not much unless you are calling it about 10000+ times a second! |
| O_o surely you would only be calling it say 60 times a second max??? |
Enough for any purpose? Or enough to slow it down?
Imo, calling it once per frame to calculate how long the last frame took is enough for any time restricted update mechanism.
| I use it for tweens and tank firing rates and I don't notice any significant slowdown. BUT-- I keep it OUT OF LOOPS! I use a Local ms:int = Millisecs() before any loop and just use the 'ms' value . |