Here are a couple of functions that might be useful re timing processes. -- Peter
Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig ---------- function microsecs put the long seconds into s set the numberformat to "#.000000" add 0 to s replace "." with empty in s return s end microsecs function exactTime -- YYYY-MM-DD HH:MM:SS.###### -- ie, down to microseconds -- times in this format can be arranged chronologically -- with an ordinary (non-numeric) sort command -- based on verboseTime() by Mark Talluto, Use-LC list -- revised by Peter M. Brigham, pmb...@gmail.com put the long seconds into s put char 1 to offset(".",s)-1 of s into dd convert dd to internet english date put word 5 of dd into tTime set the numberformat to "#.000000" add 0 to s put char -7 to -1 of s after tTime convert dd to dateitems put item 1 of dd into tYear put item 2 of dd into tMo put item 3 of dd into tDay set the numberformat to "00" add 0 to tMo add 0 to tDay return tYear & "-" & tMo & "-" & tDay && tTime end exactTime On Oct 12, 2015, at 1:41 PM, Richard Gaskin wrote: > BNig wrote: > >> BTW, what is a tick? Is that the imperial gallon of time? Or more a pint, a >> fluid ounce? >> I do kow that ticks bite and :) > > In other programming languages a tick is often a counter within some larger > timer framework. > > In HyperTalk it was derived similarly, the default update rate for the early > Mac OS vertical retrace subsystem. > > Throughout HyperTalk's life it was the most granular expression of time the > language supported, since millisecond support was introduced to the xTalk > world by MetaCard in 1992. > > The choice of tying the ticks to retrace was perhaps a necessity in early Mac > OS systems, relying as they did on preemptive multitasking. But that reliance > also made it an inexact quantity: by default the vertical retrace would > happen 60 times a second, but it was possible to have some processes run long > enough to stall it a bit now and then. > > But imprecise as it was it was all we had, so we used it. > > Today both ticks and milliseconds are independent of the display subsystem on > all platforms, and generally more reliable. > > I migrated to milliseconds for benchmarking as soon as I became aware of them > in MetaCard, since most routines are fast enough that the finer granularity > is often useful. > > If you need even finer granularity you can use "the long seconds", but with > any of them it's helpful to keep in mind the consideration Mark Wieder > reminds us of: modern multi-tasking systems can have throughput affected by a > great many considerations beyond our control. > > For this reason all benchmarks should be run multiple times with as few other > processes running as practical, and even then their results should be taken > with a grain of salt. > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > ____________________________________________________________________ > ambassa...@fourthworld.com http://www.FourthWorld.com > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode