Using standard deviation to exclude anomalies in code timing
n8wei
Posts: 2
In most of our applications, we apply a fair amount of "lazy loading", or caching techniques, which always seems to throw ANTS Profiler timings off.
Since the profiler must stop and restart IIS before starting the profiling session, there is no way for us to "preload" the application to leave those "lazy loading" operations out of the timing metrics. Thus it is very hard to drill down to exactly what in the application should be "tuned".
I was wondering if the profiler currently uses any sort of standard deviation formula to exclude anomolies caused by "first time" operations or operations which fall outside the standard deviation of all other instances of the same operation. If not, it would most certainly be advantageous to us in removing all of the noise obstructing the view of what is really in need of fixing.
Of course, there are times when customers would certainly want to see those "first time" operations, so it would make the msot sense to have this as a configurable option.
In a web application, we are most concerned about the performace once the latest build has been published, all of the static objects have been loaded into memory, and any "first time" operations have been completed.
Since the profiler must stop and restart IIS before starting the profiling session, there is no way for us to "preload" the application to leave those "lazy loading" operations out of the timing metrics. Thus it is very hard to drill down to exactly what in the application should be "tuned".
I was wondering if the profiler currently uses any sort of standard deviation formula to exclude anomolies caused by "first time" operations or operations which fall outside the standard deviation of all other instances of the same operation. If not, it would most certainly be advantageous to us in removing all of the noise obstructing the view of what is really in need of fixing.
Of course, there are times when customers would certainly want to see those "first time" operations, so it would make the msot sense to have this as a configurable option.
In a web application, we are most concerned about the performace once the latest build has been published, all of the static objects have been loaded into memory, and any "first time" operations have been completed.
Comments
Very true. The only tools at your disposal for now are enabling/disabling the profiler to cut out stats collection at the web application's first invocation, or going by the average timings in the results, assuming that the first call didn't skew them too badly.