The 2013 Q2 release of JustTrace is now available. The JustTrace team has been very busy over the last quarter and lots of new features and bug fixes have been included in the latest version of JustTrace. The new features are aimed at increasing the usability of JustTrace, streamlining its interface and providing more ways to understand how your application is actually performing.
A new and very interesting feature of JustTrace is the ability to specify a .NET executable name (full or partial) and have JustTrace “listen” for that application. When the application launched, JustTrace will leap into action and begin profiling your application.
Using this new feature of JustTrace is easy. Start JustTrace as you normally would and select the type of profiling (performance or memory) you would like to do. For this example, I’m selecting memory.
Figure 1 – Selecting the Memory Profiler
On the next screen I select “Next Application” from the list of application types. This gives me a new set of Profilee Options:
Figure 2 – Selecting the “New Application” Application Type
In the field labeled “Executable Filename Substring” I can enter either the full or partial name of a .NET executable I want to profile. Once I click the “Start Waiting” button JustTrace will begin waiting for an application to start that matches the name (again, full or partial) that I supplied in the “Executable Filename Substring” field.
Figure 3 – Supplying a partial application name
Once that application starts, JustTrace starts profiling it:
Figure 4 – Profiling the application
Close the application and you’ll have all the normal profiling data you’re used to seeing:
Figure 5 – Application profile data
This is a very handy feature. For example; let’s say you have a workflow made up of several applications. Let’s also say that there is one specific step in the workflow that seems to be using more resources than it should be. In this case I don’t want to profile the whole workflow, just the specific step that I have concerns about. I also can’t run this step in isolation because it’s expecting input from the previous step. With this new feature I can supply JustTrace with the name of the executable and launch my workflow. As the steps in the workflow that I’m not concerned with run, JustTrace waits. When the step in question is executed JustTrace will begin profiling the application and as far as the workflow process is concerned nothing is different.
Many developers will tell you that due to garbage collection and the managed runtime, .NET applications don’t have memory leaks. Those developers would be mistaken. Carelessly written .NET code can absolutely have memory leaks and they are easier to create than you might think.
A helpful way to find memory leaks is to look for changes in the number of objects at different points during the execution of the application. A great new feature in JustTrace is the ability to compare the memory usage statistics from two different snapshots taken during the execution of your application.
Figure 6 – The two memory snapshots
In the example above, I am comparing two snapshots taken during the execution of my application; one near the beginning and one at the end. Let’s take a closer look at the comparison data.
Figure 7 – The comparison between the two memory snapshots
The columns labeled “Instances (before)” and “Total Size (before)” show the metrics for the application during the first snapshot. Inn this example there were 699 instances of RuntimeType for a combined size of 19.1 KB. The columns “Instances Diff” and “Total Size Diff” show the delta between the two snapshots. In this case there was (a net of) ten instances of RuntimeType added that accounts for an additional 280 bytes of memory. If I want to drill down and get a little more information I can double click on the line for RuntimeType and see a list of object instances with some additional information.
Figure 8 - List of RuntimeType objects in memory
In figure 8 I’ve scrolled to the bottom of the list so that you can see the information for the instance of RuntimeType that was added between the snapshots. The first new object has an id of 20789 and a status of “New” which means it was added since the last snapshot. The “Age” column indicates how many instances of garbage collection the object has survived. In the case of the new object it has survived garbage collection once, while the older surviving objects have survived twice.
If I want to see who is still holding onto a reference to a surviving object, and thus preventing it from being garbage collected, I can double-click on a row and see Root Path diagram.
Figure 9 – Applications roots diagram for object id 20533
The object that is being held is the one at the bottom of the diagram. As you can see, there are a couple of application roots (blue boxes) that still have some form or reference to the object. This isn’t necessarily a bad thing; the object may still be in use by the application, in which case I would expect it to be referenced by an application root.
It’s important to note that having an increase in the number of objects or total size does not necessarily mean there is a memory leak. Your application may be adding those objects by design and not be the indicator of a problem. It’s important to do some analysis on the information JustTrace provides you and not assume that a large number of objects being added represents a problem.
As a .NET developer I spend a lot of time in Visual Studio. As such I like tools that can integrate with that environment. But while I appreciate how the tight integration of tools with Visual Studio makes my life as a developer easier, I don’t like it when tools “take over” and make me change how I work in ways I didn’t expect and don’t like. The new release of JustTrace takes steps to minimize the intrusion into Visual Studio with a new simplified extension menu:
Figure 10 – The JustTrace Visual Studio menu
The menu is short, simple with clearly named items. But, if menus aren’t your thing, JustTrace still has you covered with its concise yet fully featured toolbar:
Figure 11 – The JustTrace Visual Studio menu bar
The two most common options (Performance Profiler and Memory Profiler) are front and center and there are easy to use button for the various commonly used options from each profiler, such as restart IIS, create a call tree and profile a Silverlight application.
Most of the time you spend profiling an application is going to be spent in the analysis phase. Sometime when chasing down a performance problem and a likely memory leak you will have to drill-down several layers into different views of the profile report. You will also likely spend time switching back and forth between a couple different views to try to narrow the scope of the problem. With all the data available to you sometimes it can be hard to remember which view you were just looking at where that crucial piece of data you saw earlier was.
To help alleviate this problem, the JustTrace team has added forward and back navigation buttons to JustTrace.
Figure 10 – The back and forward navigation buttons.
These enable you to move forward and backward through the list of views you have been looking at while analyzing the profiling data. They work just like the browser forward and back buttons you’re already familiar with and can help you keep track of the data you’re looking back, helping to get rid of the dreaded “Wait, where was that very important statistic I was just looking at?!” problem.
In addition to the four great new features I described in this blog post, the 2013 Q2 release of JustTrace includes many improvements to already existing features. These new features and enhancements combine to make JustTrace more user friendly and provide the key information you need to troubleshoot performance issues in your .NET code. JustTrace is the clear choice when you need a .NET profiler, but don’t take my word for it; download the 90-day trial and see for yourself!