Millisecs() strategy

Monkey Forums/Monkey Programming/Millisecs() strategy

dmaz	(Posted 2011) [#1]

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!

muddy_shoes

(Posted 2011) [#2]

Why do you need a time value that is more precise than your frame update?

dmaz	(Posted 2011) [#3]

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

muddy_shoes

(Posted 2011) [#4]

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.

Shinkiro1

(Posted 2011) [#5]

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.

therevills

(Posted 2011) [#6]

so it seems Millisecs() is very expensive

How expensive is it?

Samah

(Posted 2011) [#7]

time = Millisecs()

Identifier not found. :)

Shinkiro1

(Posted 2011) [#8]

Oh no ... ^^
Updated post to correct version.

How expensive is it?

Too expensive if you are using it around 200+ times per second.

Gerry Quinn

(Posted 2011) [#9]

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?

GfK	(Posted 2011) [#10]

I'm going to have to look into this.

Skn3	(Posted 2011) [#11]

Yeah this surprises me that it would apparently be so slow...

MikeHart

(Posted 2011) [#12]

Calling it once per frame should be enough.

GfK	(Posted 2011) [#13]

Calling it once per frame should be enough.

Enough for any purpose? Or enough to slow it down?

dmaz	(Posted 2011) [#14]

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.

Import mojo

Global someInt:Int = 100

Class AppTest Extends App
	Method OnUpdate()
		For Local i:Int = 0 To 100
			Local ms:Int = Millisecs()
			Local a:Int = Nothing()
		Next
	End
End

Function Main:Int()
	New AppTest

	
	
	Local time:Int = Millisecs()
	For Local i:Int = 0 To 1000000
		Local ms:Int = Nothing()
	Next
	time = Millisecs() - time

	Local time2:Int = Millisecs()
	For Local i:Int = 0 To 1000000
		Local ms:Int = Millisecs()
	Next
	time2 = Millisecs() - time2


	Print "  Nothing(): "+time
	Print "Millisecs(): "+time2
	
End

Function Nothing:Int()
	Return someInt * Rnd()
End

Gerry Quinn

(Posted 2011) [#15]

A million executions in 2500 ms is not much unless you are calling it about 10000+ times a second!

Skn3	(Posted 2011) [#16]

O_o surely you would only be calling it say 60 times a second max???

MikeHart

(Posted 2011) [#17]

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.

AdamRedwoods

(Posted 2011) [#18]

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 .