clock seconds - to determine elapsed realtime
clock clicks - to determine elapsed systemtime
and various format routines to translate between them.
The problem with clock clicks is that it is platform dependent.
If you wish to do some temporal measurement e.g. profiling at the TCL
level you have to use clicks and convert
to the less accurate seconds format. If you wish to retain the accuracy
you must use
the clicks format. However, this is platform dependent, so it cannot be
compare values accross machines. Granted for profiling scripts can be
and the longer a task takes the less the accuracy matters anyway.
What I would like to see is:
clock ticks - to return a platform independent
measure of elapsed time
(say since creation of the
This would provide a regular heartbeat (e.g one tick every 50ms) and
allow comparasion of
times accross platforms. This could probably be hacked out of the
existing clicks code without
much difficulty. It could also be used for some types of
synchronisation, though thats what
events are for. Anyone care to comment?
> In article <37381B26...@rmc-ltd.com>,
> Bruce S. O. Adams <bruce...@rmc-ltd.com> wrote:
> >I notice we currently have:
> > clock seconds - to determine elapsed realtime
> > clock clicks - to determine elapsed systemtime
> >This would provide a regular heartbeat (e.g one tick every 50ms) and
> >allow comparasion of
> >times accross platforms. This could probably be hacked out of the
> >existing clicks code without
> >much difficulty. It could also be used for some types of
> >synchronisation, though thats what
> >events are for. Anyone care to comment?
> Yup. It comes up every five months or so. I'm all
> for it (or a variation). I don't find any record of
> a Scriptics person responding to the idea.
I don't know. It seems that the ANSI standard C solution of exposing
the click granularity might be better than trying to simulate a preordained
granularity everywhere. As soon as you pick a reasonable granularity,
you'll find a machine, for instance a palmtop, which cannot compute that
granularity to save its life, because its internal clock is running at
is implemented by the ANSI clock() function (or moral equivalent), then
could simply return the ANSI CLOCKS_PER_SEC value.
-- rec --
I like standards compliance (even if its not my national standard :-). This is
must. Since it comes so close to implementing 'clock ticks' as previously
why not include that in terms of 'clock frequency' to save a few lines been
endlessly. The value mentioned above 50ms was based on my memory of the Z80
I was doing speccy programming. Surely even a modern palmtop could cope with
that (even if encumbered by a dodgey M$ operating system :-). Still, point
could always add a command 'clock pulserate' which would set the tick speed and
an error if it was too fast for the hardware. How about that?
All this assumes, of course, that the clock runs at a constant speed.
Not always the case in embedded hardware, but a reasonable assumption
for anywhere you'd likely to be using Tcl. :-)
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
You could do it once per run if you can afford a little time, or run it once
per machine and leave
a file somewhere with the results.
Okay, bash me,
There are embeddable processors where the clock frequency is in the
10s of kHz range (with the clock having absolutely nothing to do with
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>