event/response delay investigation

(parent: event processing & garbage collection in Tcl and Tk)

(RJM) In a practical example it can be shown, that (at least certain) animations which are timed have a different animation performance whether the timing comes from a sort of every procedure or from a serial port event. I must stress that the difference arises only when the timing is too tight for an every procedure to execute a full animation cycle in the given time intervals. The animation in question runs considerably faster when the timing events are equal to serial port file events.

Therefore it comes to thoughts why the animation runs faster when timed through fileevents. One possibility would have been: memory freeing is cancelled upon a fileevent. Or other idle processes are cancelled (however, true interrupts would not cancel processes, only interrupt them).

The example itself is here: oscilloscope, and represents a quasi real-time data logger app which updates the canvas' contents upon each sample or couple of samples when more channels are involved. Natively, the traces are updated upon each sample value arriving at the serial port.

For the purpose of this example I added a data generation capability for two channels which is every based. Note that my results are achieved on a windows platform. Another platform might need another every, or may even fail to achieve a 1 ms resolution.

Screenshot: (the interrupted blue trace is due to a Tk bug, reported as Sourcforge 974600)

The table below shows three alternative script calling conventions together with stopwatch timing results. The measured times are based on a Pentium 1.2 GHz W2k machine running Tcl 8.5a2 and applies to 10 scans (of 400 samples each) in continuous mode. Where the nominal time should be 5 seconds, because 50ms/div is set by default (note: since each div consists of 40 samples, the interval per sample should be 1.25 ms, which is actually "everied" at 1 ms intervals).

 oscill.tcl     datadummy.tcl       comment                              time(s)
   <no arg>      <not used>         timing only every based                15
      0      <automatical exec>     every + data transfer via pipe,
                                    fileevent updates traces              14-15
    <com #>       <com #>           data transfer via nullmodem cable
                                    fileevent updates traces                6
    <com #>      <not used>         real target ([USB] target via virtual
                                    com port                                5

The worse timing in the first two cases is definitely caused by canvas' "dchar lastcurve 1" command which deletes the first element of a line which consists up to 400 coordinates, as well as adding a coordinate to a line for each new sample, hence my thought about cancelled memory freeing when high priority resp. true interrupt events occur.

The results also show that fileevents through pipes to not speed up the animation, or only very minorly.