dot.NET Profiler

This time I took part in the 13th symposium on Information Processing and Supply Networks in Hospitals (KIS, Dortmund, Germany). It was really interesting to gain insight into how technology nowadays is affecting the operations of hospitals, clinics, and their personnel management. However from my point of view, they focused too much on the hardware rather than sufficiently covering the software that drives it.

Within the healthcare system speed plays a crucial role and can often mean a matter of life and death. Here again, performance enters the picture as an important factor when developing the respective software tools.

I would like to kindly urge all readers of this blog who are working or taking part in healthcare projects to also bear in mind the performance of their dot.net developments, since noone would like to be caught in the emergency operating room waiting for protracted periods until the information pops up idly on the doctor's screen.

Long waiting periods for vitally important medical information can be avoided by testing and improving your medical software with the SpeedTrace dot.net profiler — the best and fastest on the market!

Looking around for information on profile sampling methods, I realized there was much less out there than to be expected from such a buzz topic. Therefore, I decided to make a small contribution to this subject.

First of all, I have compiled an outline to give you an idea of what a dot.net profiler sampler essentially does. The general idea of a sampling profiler is to check the target program's program counter regularly at certain intervals by using operating system interrupts. Being low in impact, this sampling approach has the advantage that it allows the program analyzed to run nearly at full speed. Yet random profiling also has its drawbacks, one of which is that it is prone to skip over information necessary for an in-depth analysis where accuracy becomes mandatory.

As you can see, dot.net sampling profilers have their pros and cons. In any case, it is useful to apply dot.net sampling whenever you need to analyze with extremely low impact. This allows you to identify the areas of an application that are causing performance problems. Later on, once the potential performance problems have been identified, it is usually advisable to switch over to a full-fledged trace analysis.

While writing this summary, I found a neat quote from IBM:

“You might have heard of the 90/10 rule: 90% of the time is spent on executing 10% of the code. Optimizing 90% of the code will have little impact on overall performance. You need to pinpoint and improve performance bottlenecks -- the 10% of the code where 90% of the execution time is spent." IBM 10 Nov 2005

This is absolutely true, since unnecessarily digging and searching in the wrong places is awfully time-consuming and hardly rewarding. However once you have roughly sounded out the problem areas, the time comes when you require full-fledged profilers with tracing capabilities to do the job. That is because ... and here's another quote:

“Developers are notoriously bad at guessing where performance problems lie, profiling can help identify them more accurately by gathering data about an executing application, and providing alternate ‘views’ of it to aid the detection process.” Simon Horrell

Although a full-fledged tracing profiler, SpeedTrace is extremely low-impact, perhaps not quite as low as the usual dot.net profiler sampler, but nevertheless the fastest profiler and tracer on the market with the lowest impact and the best returns.

This time SpeedTrace showed how it can help companies to improve their businesses.

Every year, the trade show "OOP-Software meets Business" provides information, displays solutions, and exhibits new techniques for modern companies intent on introducing best practices to their business processes.

Thanks to all attendees!