Today we are happy to announce availability of a new maintenance release of our .NET performance profiler. Please feel free to download and try the latest dotTrace 5.3.2 Performance.
Starting from this update dotTrace Performance supports the latest version of CLR. In case you have already updated CLR to version 4.5 or just plan to do it, we would recommend to use this version of the profiler.
Two quick maintenance releases to our .NET tools become available today: please download ReSharper 7.1.2 and dotTrace 5.3.1 Performance.
ReSharper 7.1.2 contains fixes to Find Usages (RSRP-336714) and auto-completion in XAML (RSRP-337050), brings a pack of unit testing improvements related to running MSTest fixtures in Visual Studio 2012 (here’s the list of fixes), and adds more updates to the installer.
dotTrace 5.3.1 Performance fixes fetching PDB files required for code preview (DTRC-8228), and improves installation in certain scenarios.
If you’re experiencing any of the issues mentioned above, please try out these new updates. However, if previous releases are working fine for you, it’s probably best to just stick with them.
dotTrace Performance allows us to profile an application in several ways. We can choose between sample profiling, tracing profiling and line-by-line profiling. Generally sampling profiling is used first to acquire a high-level overview of call performance in an application, after which tracing and line-by-line profiling is used to close in on a performance issue.
Sampling is the fastest and the least precise mode of profiling. With sampling, dotTrace basically grabs current call stacks on all threads once in a while. When capturing a snapshot, the number of calls isn’t available and times are approximate. Accuracy cannot be more than the sampling frequency.
Tracing is slower yet more precise than sampling. Instead of grabbing call stacks on all threads, tracing subscribes to notifications from the CLR whenever a method is entered and left. The time between these two notifications is taken as the execution time of the method. Tracing gives us precise timing information and the number of calls on the method level.
Line-by-line is the slowest yet most precise mode of profiling. It collects timing information for every statement in methods and provides the most detail on methods that perform significant work. We can specify exactly which methods we want to profile or profile all methods for which dotTrace Performance can find symbol information.
Line-by-line profiling is the most accurate method since it provides exact timing information on the statement level. While sampling and tracing give us an idea of the individual methods being called and their execution time, these profiling methods do not provide statement-level info. When a method body contains a lot of logic, sampling and tracing will not provide information that is accurate enough to analyze performance of that method. Consider the following source code:
If we use tracing profiling, dotTrace allows us to find out that the Foo method is taking up 98,82% of execution time. However if we look at the source code view at the bottom, there is no information provided on which statement(s) are responsible for this.
By right-clicking the Foo method, we can add this function to a line-by-line profiling session.
Once we’ve run line-by-line profiling, the source code view provides us with profiling information at the statement level. This becomes clear when having a look at the source code view below. We can clearly see that the for loop consists of 3 statements that are executed by the CLR. What’s more important though, is the color coding dotTrace uses to visualize the number of calls per statement. Line 24 is being executed 400 times, the light blue background for that line depicts that it uses most execution time relative to other statements.
Using line-by-line profiling, we are able to have a very detailed view on our application’s performance. Using sampling or tracing we can determine which methods are taking most execution time which we can drill further into using line-by-line profiling.
More and more developers are jumping on the opportunity to create applications for the Windows Store. Since most of these apps are very visual and need to be very responsive, it’s really important to know if and where there’s room for improving the application’s code. With the release of dotTrace Performance 5.3, you can now profile Windows Store applications and test projects from within Visual Studio.
As a sample project, I’ve created a simple RSS feed viewer which displays all blog posts on the JetBrains .NET blog. In the screenshot below, you’ll see that there’s a list of blog posts on the left and their contents on the right.
When using the application, everything feels smooth and responsive. Nevertheless it’s good practice to use a profiler to check if you have any potential bottlenecks. After installing the latest version of dotTrace Performance, you will find a new menu item in Visual Studio 2012 from which you can launch a profiling session.
From this menu, you can either profile the current startup project that’s open in Visual Studio, or launch a profiling session for another application. Let’s go with Profile Startup Project as you will probably have it open in your IDE.
Before the profiling session starts, you have to specify how you want to profile. Specifics on all the knobs and handles can be found in the dotTrace Web Help section. For this profiling session, I’ve selected the line-by-line profiling mode. Typically your first profiling session would be based on sampling (less precise but faster) and once you know what you are after you can have more precise results by selecting the tracing or line-by-line profiling mode. Since my RSS reader is a fairly small and simple application, I’m immediately opting for the most precise results using line-by-line mode.
After clicking Run, your application will be launched. If you’re not sure what you’re looking for, simply navigate through it and use it. I’ve clicked a couple of blog posts and waited for them to show up in the application. Once you feel you’ve collected enough information, click the Get Snapshot button in the dotTrace profiler window.
A snapshot of your profiling session is now shown. On the left hand side, you can select one of the various views available in dotTrace Performance to dive into the collected results. In the next screenshot, I’ve selected the Threads Tree. You will notice that the first two threads shown are annotated with a red arrow instead of a black one. This is because those threads have been using the CPU much more than the other threads.
It may be worth investigating the Main Thread, but most often the time shown here is the total time you have had your application running. Thread #3 in the current profiler snapshot is more interesting. It seems that by clicking just a couple of posts in the application, there’s 1430ms spent in the ItemListView_SelectionChanged method. If I drill down deeper, it looks like the TrackView method is taking 1418ms out of that time. That’s a large percentage of time!
If you look at the source code in dotTrace’s bottom pane, the purpose of this TrackView() method is to gain some insight into which posts are being read through the RSS feed viewer application. This method is obviously taking quite some time and may slow down the displaying of a post when I’m using the application on a slower Internet connection.
By profiling this RSS feed viewer Windows Store application, I’ve now successfully identified a potential performance issue even if there was no direct reason for me to go and dive in. Go and download a trail version of dotTrace Performance and profile your own applications too. It may make them much more responsive once published to the Windows Store.
Enjoy profiling your Windows Store applications!
Rolling out updates to two .NET tools simultaneously is twice as fun: please download the shiny and new
Major changes in dotTrace 5.3 Performance include:
dotTrace 5.3 Performance comes as a free upgrade for all dotTrace 5.0 Performance users, as well as for all dotTrace 4.x Performance customers who have purchased the product after February 23, 2012.
ReSharper 7.1.1 is a maintenance release that further refines performance and stability of the ReSharper 7.x family. Notable updates include:
For further details, please see the entire list of fixes included in ReSharper 7.1.1.
ReSharper 7.1.1 is a free upgrade for all ReSharper 7.x users and also for ReSharper 6.x customers who have purchased their licenses on June 1, 2012 or later.
Please feel free to download and try dotTrace 5.3 Performance and ReSharper 7.1.1!
We’ve all been there, someone calls you about the fact that the application is slow. No matter how hard you try, it’s impossible to reproduce the issue on your development machine: the issue only occurs in production. What do you do?
dotTrace makes it really easy to attach a profiler to a remote application. We’re now providing a NuGet package which makes it even easier to get your production application profiled.
Using the Package Manager Console or by using the Manage NuGet Packages dialog, you will be able to install the dotTrace Performance NuGet package into your project.
This NuGet package will verify if you have dotTrace installed on your system. If that’s not the case, it will ask you if you want to download a trial version from the JetBrains website.
The NuGet Package generates the files required for remote profiling from the instance of dotTrace installed on the computer, which varies based on the version. All this is done automatically, but it does require that you have dotTrace installed. Note that the NuGet package currently works with dotTrace Performance 5.2 and 5.3 EAP.
In the Package Manager Console within Visual Studio, we’re adding two commands:
To profile your application, simply invoke Enable-DotTrace:
After invoking this command, you will see some assemblies being added to your project. You can now deploy this application to production and start profiling.
Once you’ve deployed your application, it’s easy to attach dotTrace Performance to it remotely. The only thing you need is the URL where it lives. Simply attach to a remote application and specify the URL, e.g. http://myapp.prod.example.org/AgentService.asmx.
After connecting to the remote profiler, simply attach dotTrace Performance to the process you wish to profile.
Once attached to the remote process, you can work with dotTrace the way you are used to working with it: get a snapshot and analyze the results. After determining the root cause and deploying a fix, you can repeat the process to collect another snapshot and verify that you have resolved the performance problem.
Did you know that you can run dotTrace Performance from the command line? Why would you want to run it from the command line? Maybe you want to share the same profiling configuration across the team? Maybe you want to run it as part of your build process? Maybe you want to run dotTrace as part of a larger testing process with other command line tools?
There are lots of reasons why you might want to run dotTrace Performance from the command line. Let’s look at how we can do exactly this.
Profiling from the command line is divided into two steps. First we create a configuration file that specifies the options we want to use. Next we launch dotTrace Performance using that profiling configuration file.
For additional control of profiling, dotTraceProfiler.exe has a number of optional command line arguments:
dotTrace Performance can easily be orchestrated from the command line and integrated into your development process. Profile with pleasure!
You’ve got a thorny performance problem, but it only happens in your staging and production environments. For some reason, you just can’t seem to reproduce it on your local machine. What’s a developer to do? Fortunately dotTrace can profile a remote application and with dotTrace 5.2, it’s easier than ever before. Let’s walk through the steps of collecting a performance snapshot from a remote machine.
Step 1: Copy the dotTrace Remote Agent to the remote server
First we need some way for dotTrace to connect to the remote machine. This is done using the dotTrace Remote Agent, which ships with dotTrace. It can be found in:
C:\Program Files (x86)\JetBrains\dotTrace\v5.2\Bin\Remote
The contents of this directory are XCopy deployable. The target machine requires .NET 2.0 or greater installed. Simply copy the “.\Bin\Remote” directory to the remote server using RDP, file share, or any other file copy method of your choice.
Step 2: Run the dotTrace Remote Agent on the remote server
Log into the remote server and run RemoteAgent.exe. To profile an application running as a different user (e.g. ASP.NET web app running under IIS), shift-right-click RemoteAgent.exe and select “Run as administrator”. A console window similar to the one below will appear:
By default, the Remote Agent will listen on all network interfaces and both IPv4 and IPv6 protocols. Network traffic happens over HTTP and it defaults to port 9000. You can configure a variety of options if you need to change the defaults. Run `RemoteAgent.exe /?` for a full list of options. You will need to configure your firewall to allow TCP traffic on port 9000 (or whichever port you configured with the /port=VALUE option).
Step 3: Attach to the dotTrace Remote Agent from dotTrace on your local machine
Once the Remote Agent is running on the remote computer, you can connect to it from dotTrace running on your local machine using the “Attach To Process” button in dotTrace.
If you haven’t remotely profiled an application before, click on the “Profile on remote computer” link to bring up the Add Host dialog. If you have remotely profiled an application before, but not on this remote server, click the Add… button and enter the Remote Agent URL for that remote computer.
The Remote Agent URL will look like http://URL:PORT/RemoteAgent/AgentService.asmx. If you have connected to the remote computer before, it will be available in the drop down list.
Step 4: Profile the application
After the remote computer is selected, a list of .NET 4.0 and above processes will be displayed. Due to limitations of the .NET Profiler API, it is only possible to attach to processes running .NET 4.0 and above.
Choose whether you want to start profiling immediately or whether you would like to start with profiling disabled and click “Run”. The usual dotTrace profiling control dialog will appear. The only difference is that the performance data is being acquired on the remote computer.
Step 5: Get Snapshot and Analyze
Exercise the remote application in a way that demonstrates the performance problem and click “Get Snapshot”. The performance snapshot will automatically be downloaded to dotTrace and opened - ready for analysis.
You can analyze the snapshot data just as if you had recorded the snapshot locally. After determining the root cause and deploying a fix, you can repeat the process to collect another snapshot and verify that you have resolved the performance problem.
Profile with pleasure!
We’re happy to announce that dotTrace Performance received Jolt Productivity Award as a leading developer utility!
Starting from 1991, the Dr. Dobb’s Jolt Product Excellence & Productivity Awards are presented annually to showcase products that have made the task of creating software faster, easier, and more efficient. We are very grateful for this award, and would like to thank Dr. Dobb’s, the Jury and our users who continuously help us improve our products.
Today the insightful .NET performance profiler from JetBrains received an upgrade and we invite you to download dotTrace 5.1 Performance and try it.
Major improvements in dotTrace 5.1 Performance include:
Check out what’s new for more details or grab the latest build right now!
Please note that all dotTrace 5.0 Performance users are eligible for a free upgrade, moreover if you have purchased the dotTrace 4.x Performance after February 23, 2012 you can upgrade for free too.
Tweets about .NET tools