ANTS Profiler has shed forty pounds and had a boob job. With the bandages about to come off we take a closer look at the performance profiler, and why you need it, and we’ll see that the changes are more than just cosmetic. This is no desperate granny trying to reclaim her lost youth.

Before I go any further, if all you want to know is where to download it from, you can find it here:

http://www.red-gate.com/messageboard/viewtopic.php?t=7414

And here’s some cool stuff you really need to know:

• It’s fast, really really fast; 5 – 30 times faster than ANTS 3.
• It’s got a fantastic UI that’s been validated by a huge amount of user testing.
• The timeline makes it really easy to filter down to the performance data you’re looking for—just click and drag over the region of interest.
• The call tree shows you straight away the most expensive stack trace through your application, and if you’ve selected the right time region, that’s where your performance problem is going to be.
• The call graph has been described by a customer as “incredibly sexy”, and it makes it really easy to understand performance data in context for individual methods. It’s also great for blinding people—like your manager, or your customers – with science because you can print and export the diagrams.

EDIT: Screenshots

You can find a thumbnail gallery of ANTS Profiler 4 screenshots at:

http://www.simple-talk.com/dotnet/editors-corner/ants-4-beta-screenshots/

These have been kindly prepared by Andrew Hunter.

/EDIT


There are some things you are not going to be able to make better, in a reasonable period of time, without going back to the drawing board. For ANTS Profiler, perhaps the most obvious place where this applied was performance, about which we’d had a huge amount of feedback from users; for some applications the overhead incurred by the profiler on the execution speed was simply painful, and we could not fix that simply by patching the code – what we needed was an entirely new architecture for collecting performance data. Even then, once we had our new architecture, we weren’t sure how well it would work, so for some weeks leading up to the project greenlight, my colleague Andrew spent his time prototyping this new architecture. Encouragingly we found that it was between 5 and 30 times faster than ANTS Profiler 3.2, and I’d say being able to show a demo video illustrating this in the greenlight meeting was one of the key selling points for the new profiler.

People were initially more sceptical about the changes to the user interface, which by any standards have been radical. If you look at earlier versions ANTS Profiler you can still see some of the user interface cues that existed in ANTS Profiler 1.0 in version 3.2, and the user interface in 3.2 is virtually identical to 2.0. However, before we decided to go in, tear everything up, and start again, we did run some usability tests. These were illuminating, and often entertaining, and one of the things they showed us was that the UI was a limiting factor on finding the relevant information about performance problems, and was hindering users’ understanding of what was happening in their code, and we realised pretty quickly that this was something we needed to address.

The timeline, for example, came about because we realised it was too difficult to inspect performance data for particular actions a user might take in your application. There was a fairly heated discussion in one of our design meetings about this, and in particular about how snapshots were a completely bogus and crappy concept in the 21st century, and how they’re a workaround for technical limitations that no longer really exist, and how therefore we should ditch them like a used nappy.

So anyway, with all this user feedback, we were now in a position to see that a substantial rewrite was actually needed, and wasn’t just something we wanted to do, which let’s be honest, was all it had been up until that point. Having said that, we have kept some very key pieces of code over from previous versions: the startup code that kicks off your process and attaches the profiler, is largely the same as ANTS Profiler 3, albeit slightly refactored, and with some bug fixes. This is because starting up the target process and attaching the profiler is actually very tricky, and completely littered with gotchas and caveats of every possible description. If we’d just thrown that away without any reference to it we’d probably have spent three months just figuring out what was up, and then gone back to the old codebase anyway. It would have dragged us all down, the project would be really late, people would have got stressed out, there’d have been resignations and team changes and… you get the picture. In any case, we’ve spent enough time fixing IIS related problems as it is.

Many of you will already have tried the early access releases, so you probably won’t notice a huge difference between this beta release, and the last early access release, except that the whole thing is starting to feel more polished, there have been quite a few bug fixes, etc. For those of you who haven’t wanted to download the early access releases, this will be a complete transformation. If the bullet list at the top hasn’t been enough to convince you, let me give you three reasons why I think you should download ANTS Profiler 4 Beta:

1. It’s extremely fast; much faster than previous versions of ANTS Profiler, and in terms of instrumentation profilers that are able to provide you with line level performance data, it is unquestionably the fastest*.
2. The timeline makes it extremely easy to view performance data for any arbitrary time period within your application’s lifecycle. There are no more snapshots – a common feature in performance profilers – you just drag out the time period you’re interested in, and you’ll see what happened in that time period.
3. The combination of the call tree and the call graph make it very easy to see and understand performance data in context. For example, you can easily see that when called from certain locations, a particular method is very expensive, whereas when it’s call from somewhere else it isn’t. I’ve used call graph type interfaces in other profilers before, and frankly, most of them suck. Ours doesn’t. It’s focussed on the method you’re interested in and it makes it really clear exactly how much time its callees and callers contribute to its execution time.

*There is one caveat: if you’re unfortunate enough to be working on an application that uses .NET 1.1 you won’t notice much of a speed difference. This is because of limitations in the .NET 1.1 profiling API provided by the CLR, and in particular the lack of the fast path mechanism that became available in .NET 2.0 and later. I would still suggest ANTS Profiler 4 is a worthwhile upgrade or purchase though, because of all the other benefits.

The observant amongst you will have noticed that the beta is a few days late – I’d  originally said we’d release it on Monday, but there were a few things we wanted to fix – but we’re still planning on a September 1st release date. This doesn’t leave an awful lot of time for making changes, and indeed we’re not planning to make many, although there are a couple of things that we’d like to try to get in (as well as some more bug fixes). But that doesn’t mean we don’t want to hear from you: if you’re having problems with the profiler, or you think we’re missing a trick, we’d love to hear from you. Please post any comments to the forum:

http://www.red-gate.com/messageboard/viewtopic.php?t=7414

As those of you who have participated in the early access program know, we take user feedback very seriously, and have incorporated many of your suggestions into the product. We regard ANTS Profiler as one of Red Gate’s premier products, hence the memory profiler will, over the coming months, be getting exactly the same kind of treatment as the performance profiler. We’re also not resting on our laurels with the performance profiler, and will be continuing to look to the future, so if you have anything to say about it at all, please do let us know.

Finally, and I can’t say this enough: thanks again to all of you who’ve participated in the early access program. I believe we’ve created a much stronger product as a result of your feedback.