I've also seen benchmarks / load testing on my Mac with lots of time in
time.now, according to pprof. We were calling time.Now frequently, but it seems
this added code might exacerbate the issue.
Damian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
I ran the same benchmarks on my local linux NUC and the code actually had
small performance improvements between 1.9 and 1.10 (some better some not).
It appears to be isolated to running the benchmarks on my mac.
On Saturday, December 23, 2017 at 5:38:31 PM UTC-6, Krzysztof Kowalczyk
wrote:
>
>
Most likely
it's
https://github.com/golang/go/commit/d8ff3d592088ef175222dbf69991887f0dd458d6#diff-b884a414ef2918cd3d75c6799cb62581
which seems to add fair amount of code to time.Now()
You can see history of commits to that file with
https://github.com/golang/go/commits/master/src/runtime/sys
It did change. See https://golang.org/cl/76990 and
https://github.com/golang/go/issues/20427
.
The numbers you posted look larger then anticipated if it is the same one.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this g
Hard to get a public test case (private code), but I noticed with go10, the
profiler puts 99% flat time in time.now. Did time.now change somehow?
(pprof) top1
Showing nodes accounting for 2.11mins, 99.90% of 2.11mins total
Dropped 26 nodes (cum <= 0.01mins)
Showing top 1 nodes out of 10
fl
