Have you tried starting a simple thread which will update some variable every 100ms (for example), and then just get value of this variable? Using atomic functions. I believe memcached was 'caching' calls to get time this way and it won't probably be very accurate (as we don't have hard quarantees for doing sleep(..)) but even if it'd be +2 seconds off that shouldn't make an issue.
poniedziałek, 18 lipca 2022 o 21:34:19 UTC+2 Ian Lance Taylor napisał(a): > On Sun, Jul 17, 2022 at 6:20 AM Andrew Phillips <aphill...@gmail.com> > wrote: > > > > I've discovered a few problems with time.Time but thought I better > discuss here first before creating issues at > https://github.com/golang/go/issues (in case I missed something obvious > :). These are mainly performance issues, but there is also the serious > problem that it is easy to accidentally disable "monotonic" time > differences (reverting to "wall" time) and that you cannot obtain a > monotonic time with *Location == nil (UTC). > > > > This all began with real software that generates (using time.Now()) and > retains millions of timestamps (in memory) used for various purposes > including the deletions of old data by comparing these times with "now". > Due to the large number of calls to time.Now() performance is important, > accounting for a significant proportion of processing time. > > > > The first optimization made (some time ago) was to replace calls to > time.Now() with time.Now.UTC() in an attempt to reduce the load on the > garbage collector. (Calling the UTC() method sets the *Location field to > nil which obviates the GC need to follow the pointer I believe.) > > I wouldn't expect that change to make a big difference, but it should > help a little. What would help more is converting your stored > time.Time values by calling the UnixNano method, as that would give > you a value with no pointers at all. However, that would of course > lose the monotonic time reading. > > > > Recent benchmarking revealed that calling calling time.Now().UTC() takes > more than twice as long as calling time.Now(). Moreover, time.Now() has > some code that is effectively "dead" (never executed) which could reduce > that it by another 30% -- there is an if statement that will always return > false until after the current time is well into the future (after 2150 or > so). > > I'm a bit surprised by these measurements. Can you share your > benchmark code? Note that this is an area where microbenchmarks can > be fairly misleading. Real code does not call time.Now in a tight > loop without other memory writes. > > > > A further issue I found from inspecting the code for the UTC() method is > that calling it clears the hasMonotonic flag and subsequent time > comparisons use "wall" time - this affects many calls to > ContextWithDeadline(). The only discussion I can find on why calling UTC() > should clear the hasMonotonic flag is this comment from Russ Cox [ > https://github.com/golang/go/issues/18991#issuecomment-306209288] which > does not explain what tests are fixed or even what is being tested. > > The fact that UTC strips the monotonic time is documented at > https://pkg.go.dev/time, which says "Because t.In, t.Local, and t.UTC > are used for their effect on the interpretation of the wall time, they > also strip any monotonic clock reading from their results." > > > > I find it particularly worrisome that you can easily and inadvertently > turn off "monotonic" time comparisons. > > > > Some changes I might propose are: > > 1. Removal of the dead code in time.Now() > > The code is not dead, it just won't fire yet. On amd64 it's four > instructions including a jump that should always be predicted > correctly. We would need to see some very clear evidence that those > four instructions weigh heavily compared to the couple of hundred > instructions required to fetch the current time value (on > linux-amd64). > > > 2. Calling UTC() should not clear the hasMonotonic flag > > That would be a backward incompatible change. We can't do that. > > > 3. Passing a non-monotonic time to contextWithDeadline should panic > > That would be a backward incompatible change. We can't do that. > Programs construct deadlines in all sorts of ways. > > > 4. Add a new function (eg, time.NowUTC()) to efficiently get the current > monotonic, UTC time > > We could do that. We'd want to see some clear evidence that this > makes a difference for multiple real programs. My guess, without any > data, would be that in the vast majority of programs time.Time values > are not a significant percentage of memory. And the default value of > the pointer returned by time.Now will be a pointer to the data section > rather than the heap, so the GC should discard the pointer with a few > comparisons. So it's not obvious why it would be a significant source > of GC time. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/aa524384-4da7-49da-af84-8e83b3bda7ecn%40googlegroups.com.
