The point is that if you are timing “so much” that a 1-2 % overhead (so you must have tons of very small operations) matter to throughput - sampling will still capture enough that a representative event will be recorded.
Still, optimizing time.Now() is always a good idea but I am guessing much of the overhead is function call so it will need to be turned into a compiler intrinsic (like Java) - I’m also guessing that you are suffering sampling bias and even if you fix this you are going to detect a 1-2% overhead somewhere else in the path. You are going to end up using an in memory histogram because the recording of the event is going to be more expensive than time.Now() - unless you are going to pause the program when an anomaly is detected which is usually not viable. 1-2% overhead is actually very good for performance monitoring using a general purpose OS and GC language like Go. > On Apr 29, 2021, at 1:20 AM, Amnon <amno...@gmail.com> wrote: > > Why not use the TSC timer for your timings, and convert TSC cycle times into > durations during > post-run analysis? > >> On Thursday, 29 April 2021 at 04:04:58 UTC+1 Pure White wrote: >> Hello, >> We are doing heavily tracing, and for each func we need to get the time, so >> that’s why I’d like to optimize this. >>> > > -- > 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/e6217b6a-e598-4757-a65f-f89f4d5b7733n%40googlegroups.com. -- 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/3EA13551-412B-4355-A93A-ADDE1098C408%40ix.netcom.com.
