sanjeet006py commented on PR #2061: URL: https://github.com/apache/phoenix/pull/2061#issuecomment-2616734138
> @sanjeet006py Using nanoseconds resolution for measuring calls which themselves take less than 1ms adds considerable measurement overhead. AFAIK each call to System.nanosecond itself takes ~25- 30ns so for 2 calls you are adding double overhead. Now if the operation itself takes < 1 ms let us say 600ns you are adding a 10% measurement overhead. > > https://www.javaadvent.com/2019/12/measuring-time-from-java-to-kernel-and-back.html Thanks, it was a great article. I got two key takeaways from the article: - Minimize the number of calls to measure time. - Measuring time in millis and nanos has roughly same overhead. I was of understanding that by measuring mutation plan creation and execution only, I am already minimizing amount of calls being made to track time. I have seen time taken by mutation plan creation and execution is of the order of 5-15 micro seconds (thus, using nano seconds clock). Should we just track time taken by a single `executeMutation` call and not track at further granularity? Though for executeMutation call we should track at nano seconds granularity. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@phoenix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
