Precise timing in Python?

[Peter Hansen]

"M.-A. Lemburg" wrote:

> Peter Hansen wrote:
> >
> > Timing measurements would be necessary to ensure a sufficient safety
> > margin (run your Python program repeatedly and make sure that the
> > variation you see in the latency of its response to your pulse is small
> > enough to be acceptable), but other than that and maybe disabling the
> > new garbage collection feature of Python 2.0 (I don't know what the
> > implementation is, but it could pose a risk to a hard realtime system),
> > you shouldn't have any problems.
>
> You should also consider changing the sys.setcheckinterval()
> default of 10 to something lower -- this assures that you will
> catch signals earlier in case you use them.

That should only be necessary in a multithreaded Python application, which would not
be advisable for the application suggested.  With multiple threads, you vastly
expand the difficulty of analyzing realtime aspects of a Python program, considering
the way in which the global interpreter lock inhibits completely free multitasking.
With a single thread, I assume sys.setcheckinterval() is irrelevant.

> > Can anybody who knows describe the nature of the implementation of
> > garbage collection under 2.0?  Does it run only when the system detects
> > a cycle of references, or on a thread like Java, or what?
>
> Have a look at Modules/gcmodule.c for all the fine details.
> When automatic collection is on, the collector is invoked
> after 700 new containers (dicts, tuples, lists) have been
> created.

Ouch!  That would definitely impact realtime performance (the jitter spec, related
to latency issues).  Far better to just ensure no reference cycles are created in
the application (not hard) and disable garbage collection entirely.

Thanks for the reference, Mark.

--
--------------------------------------------------------
Peter Hansen, P.Eng.