[ANN] darzTimer, a plugin for high-res timing in development

[Dar Scott]

On Aug 9, 2006, at 2:58 PM, David Bovill wrote:

>> The plugin provides a high-precision timer for those developing in
>> Revolution with enhanced reliability and greatly improved jitter.  
>> The API is
>> available only in the IDE.
>>
>
> Don't get the basics here Dar? Timing for what??? I am not sure I  
> want more
> jitter in my Rev stacks :)

I'm still learning to communicate.

You can insert into your scripts two timing calls and a call to get  
the time between those or a call to display the time.  Like this:

on mouseUp
    darzTimerStart
    open file "test"
    close file "test"
    darzTimerStop
    darzTimerDisplay -- displays the formatted delta seconds in the  
plugin
    put "open/close time:" & darzTimerSeconds() -- delta seconds to  
the message box
end mouseUp

You now can time things that can be done only once:

on mouseUp
    darzTimerStart
    destroyRocket
    darzTimerStop
    darzTimerDisplay
end mouseUp

Before, in Windows, because of the 10 to 17 millisecond typical  
resolution available in Revolution, you had to create a loop and  
destroy a thousand rockets to get this timing.  And even then you had  
the tiny loop overhead in your timing.

Also, as in the case of the open/close test, sometimes the results  
for the first timing are not the same as the results for the second  
timing.

A tiny amount is subtracted from measurements for the call overhead.   
You can calibrate that amount by putting these lines in the same  
script that the timing is in (so it will see exactly the same message  
path):

    darzTimerStart
    darzTimerStop
    darzTimerCal darzTimerSeconds()

If you want raw timing then include this in your script:

    darzTimerCal 0

Uh, this is actually part of the experiment.  I hope to release  
somethings with an eBooklet explaining things.  And somethings  
without.  I see most cases need some hints as to why one wants them.

If you try this and get a handler not found, then open the plugin and  
change the setting from "Removed" to "Front Script" or "Script  
Library".  The first is better for timing fast built-in things.  The  
latter is better for timing scripts that use other scripts.  For very  
short times, the message path overhead is predominant and it can add  
some noise to measurements.  It is often hard to predict.

Also, the OS is always doing this and that, so you will see a little  
variation.

The display in the plugin is formatted like this:

      2,999,999.999 999 999

So if you see something like this:

              0.000 015 812

You can quickly see that it is over 15 microseconds.

Some trailing digits are gray depending on the resolution of that  
measurement.  Those are not significant.  The non-gray digits will  
turn a color such as red if darzTimer had to use fallbacks to cope  
with hardware failure or extreme drift.

You should be able to time durations up to 24 days, but I haven't  
tried that.

The plugin just sits there when not in use.  It doesn't tie up CPU  
cycles.  The library when inserted is in the message path and thus  
can slow down execution a tiny bit.

Let me know if you need more.

Dar