Quick Console not up to snuff.

When I did my BCL presentation at Code Camp Oz in April I managed to stuff up a demo that should have worked perfectly.

I was showing off the NetworkChange class that lives in the System.Net.NetworkInformation namespace (more on this in a future post). In my demo I launched a console application, wired up the events to some code that would execute when the events fired. The idea was that I could take my wireless card, insert it into the laptop and I would get some text on the console.

It was a risky demo, because I hadn’t tried it before with this particular set up. When i inserted the card my heart sank – nothing, the console window was empty. Since it was my last demo and I was pretty much close to running over time I was ready to walk off and hang my head in shame – but just before I gave up one of the audience members noticed that the output had been redirected to the “Quick Console” window.

Quick Console is a new feature that has found its way into Visual Studio 2005 (BETA 2) which captures output from applications that is destined for the console and redirects to a window inside Visual Studio itself. It wouldn’t be so bad except that its no longer appears in the actual console window which can be confusing as all hell when thats the behaviour that you are expecting but if you are coming from VS.NET 2003 it simply isn’t.

Since then I’ve been caught a number of times by this little “feature” and have spent minutes wondering why I haven’t been seeing any output. Fortunately you can disable it under Tools | Options | Debugging | General – but personally I would prefer to see the product with the feature disabled or even absent.

One issue I have noticed was performance when compared with traditional console output. Now console output performance isn’t the greatest at the best of time and if you need extra speed trimming the number of UI updates per second (or more) can really make you go faster – but by my calculations the “Quick” Console is about 3.7 times slower than the old-fashioned one.

To test this I wrote a simple program that does ten thousand iterations over some Console.WriteLine(…) code that emits the current iteration number and the number of milliseconds since the program started.

In the ye’olde console it was able to output that much text in about 2.7 seconds which is pretty slow, so you can see how much doing output this way can slow things down.

Now lets take a look at “Quick” Console. Quick Console took about 10.1 seconds to output the same amount of text, like I said, about 3.7 times slower than the other approach.

To be honest I expected it to be much worse than that given the amount of paint work involved – something that the traditional console window would have been heavily optimised to do over the years.

Performance issues aside the Quick Console has other issues which need to be addressed – some are bugs that will probably be fixed by RTM, others are by-design issues (such as a lack of colouring). It will be interesting to see if this feature is scrapped or it can be fixed.

P.S. You can download the code from here.

Trace Filtering

If you have missed my last few posts, I’ve been writing a bit about tracing in .NET 2.0, this post is no exception. An interesting addition to the tracing APIs is trace filtering. A trace filter is a class that derives from the TraceFilter class and is associated with a TraceListener via the TraceFilter property.

The TraceFilter class is pretty simple, on top of the usual methods exposed by System.Object it has a ShouldTrace(…) method which returns a boolean. The method is supplied a number of arguments which help you write code to make a decision whether tracing information should be logged.

It is important to note that a TraceFilter is not intended to be a replacement for a TraceSwitch (which are incredibly under used already), instead it is supposed to be used to provide an additional interception point if a diagnostic message does make it past a trace filter. The logic should work something like this:

The key difference (other than the API) between a trace switch and trace filter is that while trace switches are good for applying rules across all listeners – a trace filter can be applied on a per listener basis. One curious omission (I feel) is the lack of ability to specify in the configuration file the type of filter that is being wired up.

My assumption is that they intend us to have listeners supply their own filters by default, and if we want to override them, do it in code. In the code below I have written a simple trace filter “LtuaeFilter” only logs out messages that contain the answer to life, the universe and everything.

When you run the program you get a whole heap of numeric output (because I am using a ConsoleTraceListener), but notice that every number contains the text “42”.

Of course, you can filter on more than just the text of the diagnostic message, the cache argument to the ShouldTrace message is of type TraceEventCache and gives us access to useful information like the LogicalOperationStack which I wrote about in my previous post.

All in all its a nice little enhancement and will probably be used by a couple of people, however I feel that a lack of configurability post compile time means that we’ll see all sorts of wierd and wonderful implementations.

P.S. You can download the code from here.