On Sun, Jul 17, 2022 at 6:20 AM Andrew Phillips <aphillips...@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/CAOyqgcUK1XJh2j3OehnovewnCZxEgW3QsMpsu3povq0D%3D8DhDw%40mail.gmail.com.
