It’s out, it’s out, it’s out! After eight months of hard work ANTS Profiler 4 has figuratively hit the shelves, and if you’re reading this that means the product release team have put it up on our website at

http://www.red-gate.com/products/ants_profiler/index.htm

Hurrah! Now we can all relax on a beach somewhere, right?

Well, not exactly: we still have a memory profiler to build, which is a big job, and there’s plenty of other stuff going on as well. But let me tell you, after the “To all Red Gate - hey, we've done it” email that all project managers send at the end of a project, and that I’ve come to love sending, the first email I sent was to HR asking how much holiday I have left this year.

So what’s it been like? Well, overall great, and we’re all really happy with the result, which has made it all worth it, because in the middle, like any worthwhile endeavour, it had its rollercoaster moments. And a bit like running a marathon (disclaimer: I never have, and I never intend to), three quarters of the way through you hit something rather like the wall, and after that it’s all just a bit of a slog towards the release, but like I say, worth it in the end. Here are some of the highlights

The first is an email exchange that took place when Stephen sent around this screenshot of the nascent UI just after we’d slotted in a very early version of the timeline, under the title “It’s starting to come together”. (Click on the screenshots to see larger versions.)



Dom quickly replied with:

Looks like a close encounter…



And then Brian waded in with:

Or this:



Stephen’s reply:

Maybe that could be a secret game in ANTS 4!

I’ll ask Bart and see if he’s keen on some additional programming…

And then, after a surprisingly short period, Brian responded with this:

Funnily enough, we were just thinking the same thing....
 
Easter Egg :-)



And Dom again with:



That gave us all a laugh, but unfortunately we haven’t had time to embed a Defender clone into the timeline, although it would make an excellent Easter egg.

Then there’s the graph. Now this, as Stephen has already said, is the thing we spent the most time revising during the implementation phase. It was also the component that, at the green light, I’d suggested we would drop if we couldn’t get it right. We came up with great looking designs for it, but because it’s all so much to do with the interactivity, it’s not something we could convincingly capture in a paper prototype, and so when we ran the prototype against a few people the results weren’t inspiring. I remember one person saying, “Well it looks great, but what the **** is it for? I don’t see how this really helps me.” Actually, I think there was more swearing involved.

At any rate, somehow we blagged it through the greenlight—I think because we were up front about the risks, and also because I’d scheduled in three weeks just to mess around with the interactivity to avoid any nasty surprises. Predictably, when we started work on it, we still had no real clue about how it would behave; we had plenty of ideas but no way of knowing which would work. They all sounded great, but sometimes you have to suck it and see; some things we thought would work, actually didn’t at all, and overall it was very tricky to get right. Actually the process dragged on so long, and we spent so many hours sitting around talking about it, and tweaking things, that I was just about ready to can it completely: we were already looking at shipping in mid-August, rather than mid- to late-July, as originally planned—we’d invested a lot in the early access programme, and in incorporating the feedback we’d received so this wasn’t unplanned in that sense, but I was becoming enormously fed up with apparently making no progress on the graph.

Fortunately before doing anything rash we realised we were all too close to the problem, and that we needed some outside perspective on the matter, so we decided to stick what we had into the next early access build and run some remote usability sessions with it to see how people got on. I wasn’t sure what to expect, but already feeling pretty down about the whole thing, my hopes weren’t high.

We ran a couple of these sessions and got some useful feedback, on the basis of which we made a few more changes. Then Stephen and I ran another session. Our candidate profiled his application, and created a new call graph for one of his methods. We waited with baited breath… the call graph appeared... and his initial reaction wasn’t encouraging:

“Ohhhh, uh… hmm.”

Stephen and I exchanged a worried look, and there was a short pause. Then the candidate clicked on the node for the most expensive child method and, as it expanded, emitted this gleeful laugh. He carried on expanding other nodes and navigating around, with the first comprehensible words he uttered being,

“Incredibly sexy!”

From then on in it’s like a kid in a sweetshop as he continues to explore the graph, laughing, and making comments.

We realised that finally we had a winner on our hands. If it hadn’t been for the early access programme, and these remote usability sessions, something we thought was merely a “nice to have”, but which has become one of the killer features, would probably never have seen the light of day, or if it had, wouldn’t have worked nearly as well. Jason’s "sexy software" post was partially inspired by this incident.




The call graph. Right up there with Cameron Diaz in The Mask; Jim Carrey just called and he wants to dance.


Whilst all this was happening, Andrew was adding the events bar to the timeline.

Now even before we released the first early access build, some of our more intrepid developers had been sneakily grabbing builds from our build server to profile their own code, and by this time loads of people were getting in on the act. One of these was Daniel, who was (and is) working on SQL Response. He had a performance problem in a big chunk of code he’d inherited which he just couldn’t get to the bottom of. He’d tried ANTS Profiler 3, along with a couple of other products, and got nowhere, so he decided to give ANTS Profiler 4 a try. Fortuitously he picked one of the first builds with a functional events bar.

The events bar marks events such as button clicks, window activations and, crucially in this case, exceptions being thrown. It turned out that this particular bit of SQL Response was throwing lots of exceptions; hundreds and hundreds of them, over and over again, and they were being swallowed higher up in the code. Most of you are probably aware that exceptions can be expensive, and when this many are being thrown the effect on performance can be extreme. Daniel tracked down the code that was throwing the exceptions, and applied a fix to stop them happening in the first place, and hey presto! No more performance problem. Now it would be even easier because you can click on individual events, and the call tree will expand down through the relevant stack trace to the method where the event occurred.




The events bar. If this program was a mill, there’d be trouble at it.


Anyway, because a picture is worth a thousand words, here’s a montage of screenshots from ANTS Profiler 4, along with a couple from earlier versions of ANTS Profiler, for the sake of posterity.




ANTS Profiler 1.0, just in from February 2003.




ANTS Profiler 2 summary page, sporting an improved UI, and support for .NET 2.0.




ANTS Profiler 3 all methods grid. This version added support for x64, .NET 3.0, and .NET 3.5.




Bang up to date, with a typical ANTS Profiler 4 session showing an unexpected performance problem I’ve just found in Exception Hunter. It turns out that marshalling onto the main thread in this method is stealing loads of CPU time, and is happening far more often than needs be (you can see this from the source code view at the bottom). I’ll be fixing that later then.




Digging a little deeper I found that Breadcrumb.AnimationTimer_Elapsed is called by Timer.MyTimerCallback (I quickly created a call graph for AnimationTimer_Elapsed first, then created this new graph from the first one). This also shows that BreadcrumbBar.Timer_Elapsed is also using a significant chunk of CPU time. Again, by examining the source code I was able to determine that most of this is due to marshalling onto the main thread.




Here’s the new ANTS Profiler 4 methods grid, which not surprisingly confirms what I’ve already seen in the call tree and the graph. All of this goes to show that performance problems are often caused by things you wouldn’t necessarily expect.




Bookmarking and labelling the selected region for later. You can have as many bookmarked regions as you like. They are all highlighted along the top of the timeline and you can switch between them any time you like with a single click.


If you want to know more about how we went about developing ANTS Profiler 4 I’d recommend you take a look at this excellent series of articles by Stephen, our resident UI designer and usability expert:

http://www.simple-talk.com/dotnet/.net-tools/software-tool-design-the-three-rs/
http://www.simple-talk.com/dotnet/.net-tools/software-tool-design-design-by-sketching/
http://www.simple-talk.com/dotnet/.net-tools/software-tool-design-remote-user-testing/

In them he talks about how we went about researching for ANTS Profiler 4, designing the user interface using Bill Buxton's sketching method, and how cheap remote usability testing allowed us to incorporate user feedback throughout the project lifecycle.

If you haven’t seen quite enough screenshots yet there are a few more here:

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

And throughout the project I’ve posted status updates such as these:

http://www.simple-talk.com/community/blogs/bart/archive/2008/05/12/52623.aspx
http://www.simple-talk.com/community/blogs/bart/archive/2008/07/08/61902.aspx
http://www.simple-talk.com/community/blogs/bart/archive/2008/08/07/66611.aspx

There is also Jason’s article, which I referenced above:

http://www.simple-talk.com/community/blogs/jcrease/archive/2008/06/03/58172.aspx

What more can I say? If you’re a .NET developer then I think you need a performance profiler, and I don’t think you’re going to find one better than ANTS Profiler 4. Find out more and download your 14-day fully functional free trial from:

http://www.red-gate.com/products/ants_profiler/index.htm

If you have any questions, comments or feedback, we'd love to hear from you. Please post them at:

http://www.red-gate.com/messageboard/viewforum.php?f=86

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.

Over the past week or so there has been a definite sea change in the way we’ve been working on the project. Up until now we’ve been focussing on getting the major functionality implemented, collecting user feedback through the early access programme, and using remote usability sessions—sometimes with hilarious results—and then making changes based on that feedback. But now we’re definitely in release mode, and looking hard at what we need to do, and what milestones we need to hit, to get the product ready to ship. The change is subtle but definite.

 

The first milestone will be an official beta of ANTS Profiler 4. This might not sound like a particularly big deal, because we’ve been releasing early access builds regularly since the end of May, but up until now we've done no QA specifically targeting these builds, except to try and pick those that don’t crash in some really obvious way. We certainly weren’t expecting release quality from any of them. I should say that we have done plenty of testing, just not the kind of testing we do leading up to a release. The exception is that our installer has been much more thoroughly tested than would normally be the case at this point. I’m hopeful this will pay dividends in a few weeks by making release testing a lot less painful than usual.

 

We've implemented most of the major functionality:

 

• Timeline and events bar.
• Call tree, showing the most expensive stack traces through the application.
• Methods grid.
• Call graph, allowing you to focus your analysis on a particular method in terms of what it calls, and—just as importantly—what calls it, and the relative contribution callers and callees make to its execution time.

 

If you haven’t seen the call graph yet, here’s a screenshot (click on the attachment link at the bottom for a larger, clearer version):

It’s well worth having a play with, so go and get the latest build—at the time of writing this is around ten days old—from:

 

http://www.red-gate.com/messageboard/viewforum.php?f=80

 

Our last early access build will go out on Thursday or Friday this week. As usual, we’ll announce it in the forum. It will incorporate printing support for call graphs, along with a lot of bug fixes. It will also—hopefully—include the new Visual Studio add-in, which supports Visual Studio 2005 and Visual Studio 2008. You should should see an improvement over the old add-in because for many applications you won’t need to go through any further setup steps, and even if you do, it’s just that one step setup dialog, as opposed to a four step wizard. We no longer support Visual Studio 2003, although you can still profile .NET 1.1 applications; you’ll just need to start the profiler manually and run your application from there.

 

So, subscribe to the RSS feed and grab the last build later this week:

 

http://www.red-gate.com/messageboard/viewforum.php?f=80

 

Once that’s done, we need to add a few more things before the beta:

 

• Saving and loading projects.
• Saving and loading results.
• Performance counter selection.
• Some context menus.
• Getting the memory profiler working.
• Putting in all the context sensitive help, which is being written right now.
• Loads more bug fixes.
• Licensing; there will be the usual 14-day evaluation period, but to continue after this with the beta you’ll need some sort of license. We haven’t decided whether that will be a version 3 license, or whether you’ll need a version 4 license. In the latter case, if you have a support and upgrades contract your existing license key should work.

 

The beta should be functionally complete, and contain no known major bugs, although that’s potentially contentious because it really depends what you think constitutes “major”. Like the early access builds, it will be timebombed, and should expire around the time we release the final version. If all goes well, we’ll get the beta out sometime around the beginning of August. If all doesn’t go well I’ll find some weaselly way to interpret that sentence as meaning there’s no possible way that anybody could have expected us to get a beta out at the beginning of August, and no justification for interpreting it as a commitment to do so. Just you watch me. ;)

 

After that it all starts to look very much like any other Red Gate product release, in as much as there is a typical Red Gate product release any more. Increasingly, the development and release cycles are tailored for each product, to suit our evolving understanding of the market, customer needs, and the risks involved, which—by the way—we’re still learning to do. You probably think that’s a really obvious thing to do, and you’re probably right, but if that's the case you do wonder why it isn’t done that way more often by more people.

 

Anyway, I digress.

 

A couple of weeks after the beta, there should be a release candidate, unless something really heinous happens. Unfortunately, this is software, so that's always a possibility, but when it does appear it won’t contain any bugs that we intend to fix for the final release. None that we know about anyway. If anything serious comes up we will fix it, and if it's that serious we may even do another release candidate before the final release.

 

Ideally we’ll release the final version ANTS Profiler 4 into the wild roughly one calendar month after the beta. And then we’ll have a breather.

But not too much of a breather, because next on the agenda is a new version of the memory profiler, and like the performance profiler, this won’t be a minor facelift: it will be a complete transformation. Now Bullfighter's just whinged at me for using the word transformation ("Not a bad word, but a transformation refers to extensive change, and consultants are ridiculed for using words like 'transformation' for pretty much anything. Like sticking a motor on a Bianchi bicycle and transforming it into a Harley Davidson."), but hey, I'm not a consultant, and in this case I think it's entirely justified.

 

So, take home message: we want to release ANTS Profiler 4 as soon as we can. We know a lot of you are waiting for it, so we’re focussed on getting a solid beta out. Our last early access build will go out at the end of this week, so get it whilst you still can. Here’s that URL again:

 

http://www.red-gate.com/messageboard/viewforum.php?f=80

Finally, I want to say a big thanks to everyone who has been involved in the early access program and provided feedback to us, particularly those of you who've taken part in the usability sessions, which have been absolutely brilliant. They've helped in two massive ways:

1. They've largely validated the UI design, which was already based on incredibly extensive customer feedback. We wanted these sessions to either show us we were doing the right thing, or show us we were doing the wrong thing early enough to do something about it without having over-committed. We were always willing to go back to the drawing board if this happened. This has worked really well.
2. They've shown up a number of problem areas, along with a few omissions, that we've been able to correct fairly easily because we got the feedback early enough in the development cycle. I cannot overemphasise the importance of this. It's made the project roughly a month longer than anticipated, but I think it's been worth it to make the right product. If we hadn't run the EA program, and had got this feedback later on (say during the beta) it's likely we wouldn't have been in a position to make some of the changes we've made.

I'd also say that actually watching somebody using your software is a really good antidote to getting too precious or possessive about it, because you can objectively see whether something works well or not.

Thanks again!

For those of you with the stomach for this kind of thing, today, for the first time, we’ve made available a bleeding edge build of a product in development. We did admittedly trial this with Exception Hunter 1.1, but we kept it pretty quiet because it really was a bit of an experiment on many levels, and as expected there were a few headaches. But we're now feeling more confident about the whole process, so I’m very pleased to be able to tell you that you can get your hands on a very early, very rough version of ANTS Performance Profiler 4. The build numbers will change with every version so you'll find download links in the feedback forum at:

http://www.red-gate.com/messageboard/viewforum.php?f=80

Now let me be absolutely clear about this: it’s not a beta, it’s not beta quality, it really is a just a development build, so it’s rough and it might crash, or behave strangely sometimes. We’ve spent about an hour testing it to ensure the installer works and that’s it… well OK, we’ve retested it about 800 times because we kept finding bugs, and we fixed some x64 problems before we put it out, and all of that took a lot more than an hour let me tell you, but basically it’s a build we just yanked from our build server. Being the first time round though we wanted to make sure it wouldn't immediately crash for everyone who downloaded it.

So if you’re feeling brave you might want to download it and give it a try. It (probably) won’t crash your computer, and it certainly won’t reformat your hard disk. You probably won’t die simply because you installed it either, although beyond that I wouldn’t like to make too many guarantees about its stability or fitness for purpose. We’d certainly like to know what you think about the new direction we’re taking with it, so please post your feedback and ideas in the forum.

I imagine that after that blistering sales pitch you’re just gagging to get your hands on it so, before I move on to being a little more positive about the whole thing, let me just reiterate one last time that this is definitely not up to the standard of a normal Red Gate beta in terms of either quality or features.

Right, now that I've got the disclaimers out of the way, I should point out that we really are quite excited about this, and we really hope that, despite the warts, you’re going to like it.

So what can you expect from this build?

1. Much improved performance: in general it’s around 5x faster than ANTS Profiler 3 when recording both method and line level timings. It can be up to 30x faster depending upon what you’re doing.
2. New timeline, which allows you select the region for which you’re interested in viewing performance data. No need to keep stopping and restarting the data. Just run the profiler once against your application and run through all the tasks you need to perform, then drag out a region on the timeline to view performance data for the period when you performed each task.
3. New call tree, allowing you to see performance data in context and really understand what your application is up to. You can instantly see the hottest path through your application for the time period you’ve selected. You can also summarise the tree at any time to exclude all methods without source code, which makes things even clearer, and is particularly useful for Windows Forms apps, where the bulk of many call stacks is spent in the FCL.
4. Support for profiling desktop applications, windows services and COM+ servers; ASP.NET will be added later.
5. Both CPU and wall clock times are recorded, and you can switch between them at any time.
6. Three different profiling modes: method and line level timings (pretty fast), method level timings only (really fast), or method level timings only for methods with source code (really, really fast).

A quick word on ASP.NET: it's coming soon but it was giving us a few usability headaches so we decided to pull it for now because we’ve redesigned the configuration screens, and re-implementing them would have delayed the build.

Getting Started

It’s pretty simple to get going. Once you’ve downloaded, installed, and run the profiler, you’ll be presented with the project settings dialog box.

First select the type of application, then provide the required information; for example, if you select a desktop application—this can also be a console app—you need to tell the profiler where the executable is. You may need to supply some arguments, but if not you can probably just hit Start Profiling, unless you only want method level timings (see below).

The Default timing display setting allows you to choose between Wall clock and CPU timings. The difference is that wall clock time includes time spent blocking, e.g., sleeping, waiting for I/O, and so on, whereas CPU time doesn’t include this. Each setting is useful in different contexts. You don’t need to worry about changing this now, if you don’t want to, because you can switch at any time later on using the drop-down beneath the tree view.

The Profile child processes option does exactly what it says on the tin, but at the moment you can’t view any results for child processes so you may as well uncheck it. To be honest it doesn’t make a lot of difference though so it doesn't matter that much.

Note that saving/loading of project settings isn’t yet supported, but it should remember your last settings when you next start up the profiler (it might forget the application type though). I'd also recommend that if you want to start a new profiling session you exit and restart the profiler, rather than hitting File > New Profiling Session, because things can tend to get a little messy otherwise.

When you start profiling the profiler will start your application and begin collecting performance data. You’ll see that the timeline at the top of the screen also starts collecting data about your application. The orange trace shows the amount of CPU time your application is using. A word of caution here: the y-axis of the trace auto-scales to include the maximum and minimum values, but we don’t yet display any axis labels, so you won’t really have too much idea what the actual value is: just because the trace is hovering near the top of the graph doesn’t mean your process is necessarily using nearly 100% CPU time, although in general this probably would be the case. Again, we'll sort this out later so you don't have to cross check with Task Manager.

Whilst the profiler is running do whatever it is you need to do with your application to manifest any performance problem, assuming you have one, or if you just want to get an overview of your application's performance, just carry out a typical set of actions. You should find that in either situation ANTS Performance Profiler can provide you with useful information.

Once you're finished you can do one of two things. The first and most obvious is click the big red Stop button to the right of the timeline and wait for the profiler to summarise all the performance data it's collected for the whole time your application was running. You can also just close your application. Whatever you do, don't click Stop more than once. You'll end up with it just sitting there for ever and a day with no results. If you do do this, just drag out a region on the timeline and you'll see some performance data appear. Obviously we'll fix this as well in a later build.

Summarisation can take anywhere from a couple of seconds to several minutes, although I'd say 10 - 30 seconds is about average, depending upon what you've been doing, the call complexity of your application, how long you've left it running, etc. If your machine's CPU usage is at 0% for any length of time but the profiler still claims to be summarising data then probably something has gone wrong, but it's not irredeemable. As above you can just drag out a region on the timeline to see results for that region.

Once summarisation is complete you'll see a representation of all the stack traces in your application, or all the stack traces within the time period you've selected, if this is what you did. By default they're displayed top down, i.e., with root methods, such as main(), as the tree roots (for threads other than the main thread the root method will be different). You can also display a bottom up view, which not surprisingly starts at the deepest methods—actually there's a heuristic here so we only include anything that takes more than 1% of execution time—and then as you drill down the child nodes progress up to the highest level calling methods; thus main() will be shown as one or more leaf nodes.

In both views you'll find that the hottest paths—i.e., stack traces—through the application are expanded, and are shown at the top of the tree. We always expand down to (or up from) a level where there is at least one method that takes 1% or more of the total execution time. For the sake of clarity and performance, we only expand stack traces towards the top of the tree. We'll provide a right-click menu option in future to allow you to “smart expand” any method in this way without needing to click down through all the child methods manually.

Personally I prefer the top down view, but that's just me, and I think both views have their uses. Another feature I also really like, and which I think you'll find really useful, are the abridged views. These views exclude virtually all methods without source code from the tree view, which can be extremely handy if you're calling into or through a lot of library code. They're very similar to the view you'll see if you choose to profile only methods with source code, and provide a similar degree of clarity if you want line level timings. Sometimes, of course, you're going to want to see if some of the libraries you're using are guilty of slowing down your application.

These different views can be selected by using the appropriate drop-down below the tree view.

Just like ANTS Profiler 3, you can view source code, where it's available. Any method with source code will be rendered in bold in the tree view. Just click on it to highlight it and the source code view will appear. If you've chosen to profile line level timings these will be shown for your method. Line level timings for other methods in the file will also be populated in the background.

For now that's about it, although we hope there's enough there to be useful. Finally, remember, you can switch between CPU and wall clock time at any time once you've got some results. You can also do the same for timing representations: percentages are the default, but you can also choose ticks, or actual times.

We'll be making these builds available on pretty regular basis, and as each build is released we'll announce it on the forum:

http://www.red-gate.com/messageboard/viewforum.php?f=80

I'd recommend subscribing either to email notifications or the RSS feed if you want these. I'll also post here if any notable bugs have been fixed, or new features added.

Weeeeell... okay, so a cursory glance at today's news headlines would suggest that to be a rather bold claim, however a few days ago I noticed that The Daily WTF was back to its old self. I'm not the most avid reader, although I do stop by fairly regularly, so I'm not sure when it happened. On the other hand, one of my colleagues who reads it pretty much every day wasn't sure either so I don't feel too bad about it. Now obviously a website called "The Daily WTF" is more than slightly rude, however when it was renamed "Worse Than Failure" I couldn't help feeling slightly sad that it appeared to have been infected by a little of the spirit of corporate blandness, which seems inescapable so much of the time... But no longer, hurrah!

In many ways this has been a very long time coming… think Daikatana, but without the offensive advertising campaign, the disgruntled employees, or the wild expenditure on, uh, what I’ll loosely term as software development related expenses. And nobody involved, at any point, has owned (or even driven) a Ferrari. As a matter of fact whilst the protracted timescales are almost identical, thankfully that’s pretty much where the similarities end.

 

I first remember a conversation about this when Lionel and I talking about it at the office Christmas party in 2004, around six months after I’d joined Red Gate, one month after Lionel joined, and when we still only had half a dozen developers in total. Then Lionel and James discussed it again maybe a year later, but this time went some way towards working out how you might go about doing it, and then in between times there were more casual discussions involving various different people.

 

But at the time Red Gate’s focus was largely SQL, so it never got off the ground.

 

Then in mid-2007 Red Gate formed the .NET Developer Tools division. We still had only one developer tool, ANTS Profiler, but Exception Hunter’s time had come.

 

So what is it?

 

Put simply, it’s a tool that allows you to analyse your code and find the unhandled exceptions before they ever happen. But so what?

 

So this…

 

Before .NET 2.0 came along, if your application threw an unhandled exception somewhere other than the main thread, you might get away with it. You might never even know it had happened, and maybe your user would quit the application before you knew anything bad had happened, or maybe your application would slowly edge its way into a world of utter agony in which it depends more and more strangely until it eventually conks out entirely, but by this time you’ve really no way of finding out why this has happened. It’s a debugging nightmare. Back in the mists of time I was asked to fix a bug in SQL Packager that turned out to be happening because deep in the bowels of the application a background thread was being terminated by an unhandled exception and leaving the application in an inconsistent state.

 

With .NET 2.0 the situation changed radically. Bam! Suddenly your application that worked most of the time under .NET 1.1 now doesn’t work for any length of time at all because there’s this background process that regularly throws unhandled exceptions and in .NET 2.0 if that happens then your application is terminated, or in ASP.NET your worker process is killed and a new one spawned. And, unless you’ve set up a delegate to listen for one of the unhandled exception events, such as AppDomain.UnhandledException, or Application.ThreadException, you’re probably not going to get any useful information either.

 

By now we’re all pretty used to this behaviour, and as a number of other authors and speakers have pointed out, it’s actually a good thing. And it’s certainly a lot easier to debug, assuming you do yourself the favour of setting up these event listeners and logging the exception information (including inner exceptions).

 

However, what this completely fails to address, is that when your application suddenly goes unexpectedly KERBLAM!!! out there in the field when it’s being used by a real customer, it’s also extremely embarrassing. You really don’t want that to happen. Many of us will have sat on both sides of that fence. It annoys your customers, it causes stress and hassle for your support team, who are probably going to have to deal with somebody actually foaming at the mouth, if not actually spitting burning jet fuel, and it soaks up time from your developers and testers, who are quite likely working on different projects by now, so the knock-on is that it hurts those new projects as well.

 

And it takes time, time during which your customer isn’t likely to get any happier. We tried an experiment recently, which was to see if we could get a patch out the door to a customer within a few days, even as a private release with extremely limited QA time assigned to it. We failed miserably. We failed because it’s not realistic to get the three or four people we needed to do all the things we needed in a very short period of time to do so when they’re all working on different projects, all of which have problems of their own. In reality what we ended up doing was rolling up perhaps a dozen fixes of varying levels of severity into a private release, each of us involved set aside an entire day to do the work we needed to do, and in total the whole process took around four weeks. And we’re a pretty small company in the grand scheme of things. For larger companies the situation is clearly going to be worse.

 

And whilst the “time is money” analogy can be taken too far, in this case time is money. Lost time equates to lost, or delayed sales. Too much lost time can equate to a failure to consolidate a product’s position in the market before other competing products are released. That sounds pretty extreme, but it can happen, and it does happen all the time. How many software products are delayed because they’re plagued by stability problems? Wouldn’t it be great if you could find and fix these issues before a tester even touches a piece of functionality, never mind a user?

 

The point is, you definitely want this stuff fixed before it goes out the door. It’s also entirely unrealistic to expect that your testers are going to find absolutely every scenario in which an unhandled exception can bring your application down before you release, even if they’re really good. Trust me, I know. At Red Gate the developer to tester ratio on every project we’ve run since I’ve been here has been somewhere between 1:1 and 2:1, and 1:1 is pretty common, even if for only part of the project. Some tools do even better: 3:4 in one case.

 

But still, you can’t find everything, and still your application can crash embarrassingly once it’s been released to the world at large, which is where Exception Hunter comes in.

 

Exception Hunter is a compile time analysis tool that analyses your assemblies and dives down into their dependencies to find out which exceptions your code can throw. It works by allowing you to pick the methods you want to analyse, shows you which exceptions they throw, and allows you to drill down through the stack traces to find their exact origin. Once you’ve found the line of code you’re interested in you can open up your source at that exact line in Visual Studio for editing. At this point you might choose one of the following courses of action:

 

• Catch and handle the exception by performing some alternative logic to do what you need,
• Wrap the exception in a domain specific exception type that you’ve created, or in some other different but more appropriate exception type, populate it with an informative message if you think you might report it to a user later, and then rethrow it,
• Wrap your code in a try block, then add a finally block to perform resource clean-up, then add XML documentation comments to your code indicating that the exception is thrown,
• Choose to do nothing in that method, but instead deal with the exception or perform clean-up at a higher level.

 

You might also find that the exception isn’t particularly interesting. For example, you’re 100% confident that the values you provide to a method will always be valid, and that therefore the ArgumentOutOfRangeException that is nominally thrown will never occur, so you never need to worry about it. That’s fine: you can and should make value judgements like that, but at least you’re now in a position to do so in an informed manner, rather than guessing and hoping.

 

You can also use Exception Hunter when you do get a crash report. So, you get the (probably obfuscated) stack trace back from the customer, or from your website logs, and figure out what’s going on, but you might legitimately wonder if anything else can go wrong. It’s a great time to run Exception Hunter over the offending code to see if there’s anything else that might catch you out. I did exactly this when fixing a problem with the meta-data cache in SQL Prompt, and managed to find three more potential problems in less than five minutes. I was then able to fix these before they caused any trouble.

 

Exception Hunter works with code written with every version of .NET from 1.1 right through to 3.5. It can analyse code originally written in C#, VB, and Managed C++. It also provides more limited support for J#.

 

You can find more information about Exception Hunter, including a demonstration video, at:

 

http://www.red-gate.com/products/exception_hunter/index.htm

 

You’ll find the support forum release announcement at:

 

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

 

 

Look, temporary tables:

This also works for normal tables created in the script, as well as stored procedures, functions and views, and it'll all be available in the next SQL Prompt release, which should be within about two weeks all being well.

Originally this functionality was slated for SQL Prompt 3, but as you'll all be aware that took rather longer than we expected and we ended up dropping much of what we'd hoped to put in there. We're working on an article about that joyous saga that will appear on Simple Talk, hopefully in the next few weeks if I get time to finish it off (sorry Tony, Phil).

Also coming in the next release:

• Data Dude support - both because it's technically easier than not supporting it (or so we originally thought), and because we've actually had quite a number of requests about it come in over the past month or so.
  
  
• CTE support - never something we originally planned on supporting in SQL Prompt 3, but it's new functionality in SQL Server 2005 and is something we felt we should probably handle, although it's far from clear to me at least how popular these are.
  
  
• Control flow statement support (IF, WHILE etc)- these previously didn't work brilliantly, which was less than ideal if you were writing a lot of functions or stored procedures, so we've shored up the support considerably.
  
  
• Loads of bug fixes, plus some more tweaking of the performance. Notably, again because this could be enormously irritating in some situations, the popup no longer appears when you're entering an alias for a table, view etc in a FROM clause.

As I say, all this should be available in the next couple of weeks or so.