dot.NET Profiler

The new community test preview of SpeedTrace as 64bit Version is now available for downloading!

Download details:
SpeedTrace 3.3.19
Community Test Preview
64-bit version.

• US download server
• European download server

The community test preview of SpeedTrace as 32bit Version is now available for downloading!

Download
SpeedTrace 3.3.19
Community Test Preview
32-bit version.

• US download server
• European download server

The editors of the free software source newsletter, FileCluster, regularly present awards for software products that perform above average in their niche. The respective software is tested carefully and evaluated according to performance, design, bugs, user rating etc.

SpeedTrace has just been awarded with five stars:

And here are the details:

http://www.filecluster.com/SoftwareDevelopment/Debugging/Download-SpeedTrace-Pro-32-bit.html

The community test preview of SpeedTrace as 32bit Version is now available for downloading!

Download
SpeedTrace 3.3.18
Community Test Preview
32-bit version.

• US download server
• European download server

Download latest 10-day CTP version!

SpeedTrace is developing fast! New unique features have been added to SpeedTrace only since my last entry a couple of months ago.

This calls for the new downloadable SpeedTrace CTP (Community Test Review) 10-day test version currently on display for review:

Download from Europe/world:
http://www.ipcas.com/trace-and-profile/download.html

Download from the USA:
http://dotnet-profiler.com/get-net-profiler-and-tracer-now/

We would like to welcome you to a new download of our latest beta version. You can now test it on your own dotNet applications and take part in the SpeedTrace development process by sending us your feedback. We would be thrilled to receive your comments.

Unique selling properties!

Here are some of the new version’s unique selling features:

• Elimination of excluded items – permits you not only to exclude but also to eliminate specified methods, for example wait operations, which may not be required at the time and would otherwise slow down the application run by up to a factor of 10. This avoids time losses (for drilling to the root) on waiting or other functions you do not want to analyze.
• Filter optimization – has been accomplished on the export recording filters, allowing you to focus even closer on the functions relevant to performance.
• Tracee arguments filter – only records those tracees whose program start arguments match specified arguments. This in effect enables you to start processes externally and zoom right into the problem areas using the start arguments to focus on individual server functions, for example, within a work distributed hosting component system.

All this saves you loads of calculating capacity, runtime and energy!

Essential improvements!

Other features have been improved considerably:

• Hierarchical caller-callee – shows all "children" and further offspring in the caller-callee view, which enhances drill-down functionality to a great extent.
• Showing all children as "flat" for hierarchical profile views – enables you to view the hotspots of the executed function without expanding child nodes.
• Comparing profile results – is important to know whether changes made within your code have a positive upshot or predominantly negative side effects. You can compare
  profile results with counterpoint method timings and allocation issues.
• Call history/filtering – represents (in text and graphics) the contribution/distribution of execution times from a selected function, now allowing you to make inferences directly from any opened profile to the trace in order to see the callees of a given function. Whenever an item is double-clicked, a second instance of Trace Analyzer will be opened showing exclusively the calls made within that segment.

With the enriched call history/filtering function, developers and testers no longer have to go through the lengthy routine of first profiling, then locating the performance problem, setting the filters to reduce the scope of analysis, and finally, tracing their application. Now you can jump from the profile to the trace analysis in less than three steps!

Even more user-friendly!

Additional improvements:

• Multi-column thread display – allows the user in the Trace view to see the sequence of thread calls made during program execution. Right-clicking on the header control and selecting Show/Hide columns will provide the number of threads available to be shown at one glance. Separating the columns helps the user to recognize the activities performed by specific threads.
• Minor UI improvements:
  – Open branch in new tab with CTRL+N
  – Hot-tracking of child nodes
  – TSC drift checks
  – Added start arguments to summary

In the entries to come I would like to lead you through a tour taking a closer look at the most unique features this tool has.

In the meantime, have fun testing the new tool version and don’t forget to send us your comments! Join in on the development process to best suit your own application!

For general information on SpeedTrace and its unique features, please also visit our website:

http://www.ipcas.com/trace-and-profile/c-sharp-and-vb.net-tracer-and-profiler/

I was on the road the last few days counseling our clients on how performance issues can be detected in .NET applications. Upon perusing my last entry once more, I realized that my account was not complete, since I haven’t yet informed you about the new features SpeedTrace 3.3 is going to bring to the market soon. Therefore, I’d like to just provide you with a short outline of some of the coolest features this tool has.

SpeedTrace 3.3 features:

• Tracing of multiple processes:
  You can run several instances of SpeedTrace in parallel, so you can profile/trace different processes simultaneously in order to help you to focus on certain segments of your application at the same time.
• Call history scoping:
  SpeedTrace enables you to open partial traces just to see the callees of a given function by focusing exclusively on the calls made within a given segment.
• Generating trace output from a terminated process:
  An application that terminates unexpectedly may cause a real headache and waste a lot of time if you cannot analyze its cause properly. Due to SpeedTrace’s robust architecture, it yields reliable results thorough to the last drop even when your application crashes.
• Hotspot filter:
  Whenever you activate it, SpeedTrace will only display the nodes with own times higher than the specified threshold.
• Comparing profile results:
  It is important to know whether changes made within your code have a positive upshot or predominantly negative side effects. You can compare profile results with counterpoint method timings and allocation issues.
• Triggers: Specify the method that will start or stop the profiling process in order to analyze specific behavior within specified boundaries.
• Black box filter:
  3rd party components that cannot be improved always flood the analysis with irrelevant information. SpeedTrace, however, can encapsulate these components by just providing transitions for the ones you need.
• Data trace:
  SpeedTrace helps you to locate bugs (e.g. programming errors, deadlocks, missing or wrong version of DLL) easily, allowing you to examine the data flow channeled through the various functions.
• Code location in Microsoft Visual Studio:
  Whenever you find an issue, a quick tune of the code is required. You can always click on the Source view in SpeedTrace to locate your code in Visual Studio.

In many msdn blogs I have noticed that people are trying to understand why certain dll’s or function/methods show up in their performance analyses contrary to their wish after profiling their application with VS.

Usually, one can use a dot.net sampling profiler to drill down to the problem of an application. Yet having done that, what if the sampling data does not provide the relevant data and sufficient information? Well, for every question there is, of course, always an answer: a trace profiler can offer more and important detailed information, especially if your application works in a multithread environment. On the other hand, every solution also has its drawbacks, and this is no exception. Therefore, when you profile a huge application, you may find that you’ll be flooded with information in a huge trace result, and your application’s performance is liable to be sensitively impaired by the procedure on top of it.

However, the SpeedTrace dot.net profiler, finally offers you a way out of this dilemma! Thanks to its three-level filtering approach (illustration below), you will be able to avoid (and reduce to a minimum) the unnecessary information that normally holds you back when tracking down the essential performance issue. Besides, by thus streamlining its tracing and profiling capabilities it also prevents the impacts that normally occur to your applications’ performance when you subject them to these kinds of procedures.

And this is how it works:

• The recording filter (only available in the Pro version) first collects all method calls and is apt to maximize trace speed, minimize resource usage (memory, time, power, etc.), and minimize the bulk of information
• The pre-processing filter (available in the Basic and Pro versions) then works on the traced calls and further minimizes resource usage and minimizes the information to what is relevant and sufficient
• The post-processing filter (available in the Basic and Pro versions) finally filters the pre-processed calls and minimizes the information to that which is quintessential, leaving you with a perfectly profiled and thoroughly useful account of your problem.

The bottom line of the story is:

The SpeedTrace filterering system is simply a tool you cannot do without when bug trapping your application!

Level of Filters

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.

I have seen different people looking for a dot.net profiler able to analyze their .Net Compact Framework applications. It is easy to understand why people should seek to solve issues within this arena since mobility is the trend nowadays.

In the article, Instrumentation in the .NET Compact Framework written by Scott Holden, he mentions how important it is to provide high-performance solutions since that is the issue you address with your customer.

Moreover, the Developing Well Performing .NET Compact Framework Applications article mentions the importance of analyzing algorithms written by developers as a performance measure:

In some cases, it will also be required to focus on parts of an application that call many functions. Therefore, a developer should know how to determine these durations for later comparisons between designs.

That is why I’ve decided to show you now how the SpeedTrace dot.net profiler is able to help you to analyze algorithms also written for .Net Compact Framework since you will then be able to see calls made during execution in order to analyze design issues.

The following example uses a dot.net application which establishes a remote desktop connection via vnc. It is analyzed before the application is deployed to the PDA, since SpeedTrace does not yet offer a dot.net compact profiler at the moment.

Application running in the Smartphone emulator

For our analysis, we will be using the .exe file compiled by Visual Studio (also located in the debug directory).

The first step is to create a new generic project in SpeedTrace and to locate this dot.net application. We keep the default values for a quick start.

New Generic Project

Once the application has been selected and the SpeedTrace dot.net profiler is ready to analyze it, we can activate the project and start to record it. The Smartphone application will open, so we can add the server and password information.

Recording

SmartPhone application

The application connects to the designated server. At this point we have enough information for our analysis. Let us take a snapshot without detaching our application; we may need to continue analyzing later.

Snapshot

The SpeedTrace dot.net profiler generates the output file and requests the type of output we want to use. In this example, I have used the ‘Profiling Data only’ option.

Trace Output Generated

The Trace Analyzer opens and shows the Performance Summary of this dot.net application.

Summary View

In this case absolute times are not representative since resources within PCs are completely different from the ones in PDAs. However, “relative times” (time contribution) can be compared to solve algorithm-related issues. Moreover, the number of calls plays an important role, too, whenever it is necessary to see whether too much processing was done; the number of calls should be equal for both platforms.

At this point, I have illustrated how the SpeedTrace dot.net profiler can also be useful under Dot.Net Compact Framework. The rest is up to you. All you need to do is apply filters and triggers in order to focus on specific parts of your dot.net applications.