There are so very many practical cases where this lighter Zt will be useful.
It just goes nicely with don't build what you won't use. Inserting time into generated web page meta content is one; fast "bookmarks" is another (with offset UTC set to hard-coded -00:00 ) R On 22 June 2012 19:14, Paul DeBruicker <[email protected]> wrote: > Yes I agree there's a need for speed. I think ZnTimestamp is a valuable > addition. > > And maybe the primitive that returns ms since epoch and offset gets adopted > so DateAndTime can be nearly as fast. > > > > On Jun 22, 2012, at 2:51 PM, Sven Van Caekenberghe <[email protected]> wrote: > >> >> On 22 Jun 2012, at 22:23, Paul DeBruicker wrote: >> >>> On 06/22/2012 01:11 PM, Igor Stasenko wrote: >>>>>> Here are some benchmarks: >>>>>> >>>>>> [ 1000 timesRepeat: [ ZTimestamp now ] ] bench '1,910 per second.' >>>>>> [ 1000 timesRepeat: [ DateAndTime now ] ] bench '253 per second.' >>>> what? 253 per second? what it doing there? >>>> >>> >>> 253 iterations of 1000 timesRepeat:[DateAndTime now] per second. >>> >>> So ~253,000 iterations of DateAndTime now per second. >>> >>> [DateAndTime now] bench >> >> Yes, depending on the use case one can discuss about the absolute numbers. >> >> But consider a LRU style cache where on each operation the timestamp is >> updated to now, you'll want speed, right ? >> >> Sven >
