So I have again been making games, and i want to test if there is any was to apply a stopwatch on my function but the function runs without screen refresh.
So, any way/ideas?

uhh

You can store the timer to a variable at the start of the function and then subtract that from the timer value at the end.

Hi Orange_Gumdrop,

Use

(days since 2000)

to record your start and stop times. Once you take stop-time - start-time, you'll have to multiply up from days to whatever time unit you want for your duration.

I think I read the (timer) block only updates once per frame, but (days since 2000) access the underlying system clock as it's processed.

EDIT: Confirming. I just tried my test (below) with the timer block instead of days since. Timer reports the exact same value in my before and after.

set [before v] to (days since 2000)
... // your function
set [after v] to (days since 2000)
set [duration v] to (((after) - (before)) * ((24) * (3600))) // duration in seconds

I just tried this on 10 repetitions of a couple move blocks, inside a custom block with no screen refresh, and clocked it at 0.002… seconds

If your function is fast enough, the variable monitor (orange variable display) may show 0 if it can't display enough decimal places. Drag the (duration) block onto the editor and click it to see it has a non-zero value. You may need to multiply it up further and call it milliseconds.

I hope this helps,

– RT_Borg

What I typically do is time the block running multiple times, in a script that looks like this:

tester::custom
define tester 
// run without screen refresh
set [time v] to (days since 2000)
repeat (5000)
custom block::custom // what you want to test
end
set [time v] to (((86400) * ((days since 2000) - (time))) / (5000)) // 86400 seconds in a day, repeat loop runs 5000 times

Something I wish I knew sooner is the timer block isn't that accurate. Days since 2000 is very accurate, so use it. I'm not sure why but the timer seems to run at slightly different speeds depending on framerate. When testing a custom block like the above, the framerate can drop substantially because it's forcing scratch to run as much of it as it can.

Hey awesome-llama,

Timing with “days since 2000”, I was wondering about the granularity. On my system I was seeing it discretized at approximately 1 ms values.

I dug into some interesting reading about the underlying Windows Timer Resolution (some stuff I brushed up against \u232B \u232B mumble mumble years ago).

The summary is that the timer granularity on Windows machines comes from a system timer interrupt interval. The interrupt can be set to trigger as fast as 0.5 ms, but may be much slower. Different versions of Windows have different default timer interrupts. Applications that request a higher interrupt frequency change that interval globally. (Some applications like Chromium based browsers request higher frequency interrupts, but cap their request on battery-powered systems to 8 ms, since servicing this interrupt is a power drain.) Microsoft also has a handy tool to see your current system clock resolution: https://docs.microsoft.com/en-us/sysinternals/downloads/clockres . (There's also a Windows System Timer Tool in common use that lets you modify your system timer interrupt value, but I won't link that since it's written by a 3rd party, and people who don't know what they're doing generally shouldn't mess with their system.)

All that said, awesome-llama, you're right that measuring a large number of repetitions vs trying to profile a single fast set of blocks is the way to go. (Even apart from the resolution issue, I see a fair bit of variance on one-shot timing when the duration is down in the low millis.)

– RT_Borg