0

I am trying to register how much time each method takes to execute. I do not want to use any 3rd party tools which does this. I also looked at few older posts that have some suggestion but they are pretty old, so I am looking for recommendation if there is a newer way to do it. Also, this instrumentation logic should work with .net core and .net full framework.

I do not want to do something like this

class myClass{
    public void mytest(){
       StopWatch sw = new StopWatch();
       sw.start();
       // DO SOMETHING
       sw.stop();
       log(sw.elapse());
    }
}

Also, I want to tie everything to a ID and do not want to pass the ID to all the methods which would be a lot of work. So, want to create an interface and it does all the performance logging for all the methods which are used.

Please let me know if this is not clear enough. I can provide with any clarification.

What I am writing is a Nuget Package. This nuget packagae can be used in a .net core webapp or it can be used in a legacy WCF application. With that said the nuget package received a request, it then does some business logic and then calls a geospatical database. What I am looking for is a way to know the duration of each call that is done in the business logic or calling the DB. The reason for this is that when the geo data changes, some queries that we have may not function optimally or some others rules set in the business logic could become unoptimized and hence I would look at this speeds to see where the issue is and debug it accordingly.

jack
  • 321
  • 1
  • 5
  • 20
  • 1
    Please read the speed rant, to verify that you actually need this: https://ericlippert.com/2012/12/17/performance-rant/ | If you still want to do this afterwards, I would generally advise for using existing options. As as the Article says, writing usefull Benchmarks is not trivial and easily done wrong. – Christopher Dec 11 '19 at 21:13
  • especially automated ways of doing so is hard since you have to rewrite/inject il. – Daniel A. White Dec 11 '19 at 21:13
  • I am already using DI container to in my project. Does that solve some of my concern. – jack Dec 11 '19 at 21:24
  • Instead of using a stopwatch, just keep track of the DateTime.Now.Ticks value. Keep a record of the ticks in start and end, then you know the duration by Timespan.FromTicks(afterTicks - beforeTicks). If you want to get fancy then make a class to provide a Start() and Stop() method that can track the calling method and generate some reports for you. – Zakk Diaz Dec 11 '19 at 21:25
  • @Christopher what would be your recommendation that I should do ? – jack Dec 11 '19 at 21:34
  • @ZakkDiaz That is very incorrect, unless you got runtimes in the order of 10's of Milliseconds. The result of DateTime.Now only updates every ~20 ms. The stopwatch is actually reliable. | But even with that, you can not account for GC runs and the like reliably. As those only happen intermitently. – Christopher Dec 11 '19 at 21:42
  • @jack First you should show us you read the speed rant, by explaining why you need this and wich of the dozen or so "speeds" you want to optimize for. – Christopher Dec 11 '19 at 21:43
  • @Christopher : I updated my question with a scenario why I am looking for this. – jack Dec 11 '19 at 21:51
  • @Christopher You're right I wasn't aware of the refresh rate of DateTime.Now or that it could be affected by garbage collection. From the OP I was under the impression they didn't want to use a stopwatch. My suggestion for reflection with the method name was an attempt to remedy the need of passing an Id along. I fully anticipated that the process would take more than a few hundred MS, OP didn't state they are writing highly performant code. – Zakk Diaz Dec 11 '19 at 21:53
  • https://stackoverflow.com/questions/307582/how-frequent-is-datetime-now-updated-or-is-there-a-more-precise-api-to-get-the https://learn.microsoft.com/en-us/dotnet/api/system.datetime.now?redirectedfrom=MSDN&view=netframework-4.8#System_DateTime_Now – Zakk Diaz Dec 11 '19 at 21:57
  • @ZakkDiaz Either measurement approach can not properly account for the GC. It is an issue in .NET | You could call a whole bunch of that function in a loop and then call GC.Collect() before getting the end time for this cycle. However that would only get you a lower bound, as the runtime for the GC increases the more elements (collectable or not) there is in memory. | Unfortunately Eric posted his posts about how to do it "right" on a Blog that is no longer reachable. So that is about the best I can do. – Christopher Dec 12 '19 at 00:56
  • Thank you guys. But the discussion that you guys currently had is not what I was looking for. Thanks :) – jack Dec 12 '19 at 16:27

0 Answers0