[Lazarus] EpikTimer v1.0.1 released

[Tom Lisjac]

On Mon, May 26, 2014 at 3:38 AM, Michael Schnell <mschnell at lumino.de> wrote:

>
> I use EpikTimer in my (soon to be released) work on the ActiveNoGUI Widget
> Type.
>
> Here I found, that it is a rather appropriate use for EpikTimer to handle
> it in a "static" way, not creating an instance of TEpikTimer with every use
> of same, but simply to use class properties, class procedures and class
> functions of TEpikTimer.
>
> The advantage of this is that the overhead when creating an EpikTimer is
> reduced to zero.
>
>
Hi Michael,

I'm having a little trouble understanding where new functionality is needed
for your use case. With the existing code, you don't need to create an
EpikTimer instance each time you need a new timer. A single instance
supports an unlimited number of timers using the TimerData record from the
EpikTimer unit:

TimerData = record
  Running:Boolean; // Timer is currently running
  TimebaseUsed:TimeBaseSelector; // keeps timer aligned with the source
that started it.
  StartTime:TickType; // Ticks sample when timer was started
  TotalTicks:TickType; // Total ticks... for snapshotting and pausing
end;

You can declare any number these records to create as many timers as you
need. Here's an example for a single ET instance of EpikTimer:

Function TimedExecution: Extended;
Var
  i:integer;
  TimerA,TimerB:TimerData;
  TickTick:Array[1..1000] of TimerData; // if you need a thousand timers
Begin
  ET.Clear(TimerA);
  ET.Clear(TimerB); // Declared timers must be cleared before use
  For i:=1 to 1000 do ET.Clear(TickTick[i]);

  ET.Start(TickTick[someindex])

    ET.Start(TimerA);
    ExecuteTimedSectionA;
    ET.Stop (TimerA);

    ET.Start(TimerB);
    ExecuteTimedSectionB;
    ET.Stop (TimerB);

  ET.Stop(TickTick[someindex])
  etc...

The mechanism is pretty efficient as the record for each timer is only a
few dozen bytes. One instance is necessary to do the initialization that
detects the available timebases and does a rough overhead calibration for
system calls. There's always going to be edge jitter with userland calls,
so calibrating each timer wouldn't add certainty to the overall measurement.

If I'm not understanding the problem you're trying to solve, could you
please explain it a little further?

Thanks,

-Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20140528/bd11aaea/attachment-0003.html>