Pigs Can Fly : Source Code

StackOverflow answer – why learn multi-core programming? #2

rgr — Thu, 06 Aug 2009 20:40:00 GMT

In my last post I talked about how multi-threading can be used to improve responsiveness while loading a file. I’ve put together a sample program (source included) that shows how to do this in C# 3.0, .NET 3.5, and WPF using Visual Studio 2008. You can find a zip file with a complete project attached.

The program has a very simple, but fully functional UI.

The “Open a file…” pops up the standard open file dialog and ask the user to find a file. The cancel button is disabled unless there is a loading operation to cancel. The text box is for messages from the loader thread and the slider is just there to show that the UI is responsive while the background load occurs.

The progress bar is hidden unless a file is actually being loaded. If the async check box is un-checked, then the file will be loaded synchronously. This illustrates how the UI will ‘freeze’ if a second thread isn’t used.

The key thing about this program is that the UI stays completely responsive while a file is loaded. Of course, this can be done without threads – many programs are written using a state machine approach. But using threads, and functional programming make this much more simple than previous approaches.

There are many ways to leverage threads in managed code, but the most straight forward way is using the BackgroundWorker class. IT can be used in two ways, by creating one and attaching functions to its delegates, or by creating a new class derived from BackgroundWorker – this is the approach I took here.

I created a class called AsyncFileLoader that is derived from BackgroundWorker. We’re using all the features of BackgroundWorker here

Support for asynchronous progress notifications
Support for cancelation
Handling of errors during the file loading

Progress and cancelation is enabled by setting their properties in the constructor.

   1: public AsyncFileLoader()

   2: {

   3:     WorkerReportsProgress = true;

   4:     WorkerSupportsCancellation = true;

   5: }

We also need an event handler that will be connected to the cancel button

   1: public void PerformCancel( object sender,  RoutedEventArgs e )

   2: {

   3:     this.CancelAsync();

   4: }

The final element is a function that overrides BackgroundWorker.OnDoWork(). This function does all the work of asynchronously loading a text file.

   1: protected override void OnDoWork( DoWorkEventArgs e )

   2: {

   3:     // note: do not catch exceptions here.  The BackgroundWorker will catch exceptions

   4:     // and pass them back to the initiating thread in the RunWorkerCompleted() delegate

   5:     // using the error member of RunWorkerCompletedEventArgs parameter.

6:

   7:     string FileName = e.Argument as string;

8:

   9:     ReportProgress( int.MinValue, String.Format( "Opening {0}", FileName ) );

10:

  11:     using ( StreamReader sr = new StreamReader( FileName, Encoding.UTF8 ) )

  12:     {

  13:         ReportProgress( int.MinValue, String.Format( "Loading {0}", FileName ) );

14:

  15:         long FileLength = sr.BaseStream.Length;

  16:         long PercentRead = 0;

  17:         long LastPercentRead = 0;

18:

  19:         String line;

20:

  21:         while ( (line = sr.ReadLine()) != null ) {

22:

  23:             if ( CancellationPending ) {

  24:                 e.Cancel = true;

  25:                 break;

  26:             }

27:

  28:             PercentRead = (sr.BaseStream.Position * 100) / FileLength;

29:

  30:             if ( PercentRead >= LastPercentRead + 1 ) {

  31:                 ReportProgress( (int)PercentRead );

  32:                 LastPercentRead = PercentRead;

  33:             }

  34:         }

  35:     }

  36: }

As you can see – this is really simple, and most important procedural – there isn’t a state machine, or any explicitly state kept at all. This single function loads the file, and sends progress messages and errors asynchronously to the calling thread.

The initiating thread passes the background thread parameters using the DoWorkEventArgs class. Here, I’ve simply passed the file name as a string, but any class or structure could be passed this way.

Line 9 is important – it asynchronously passes the first progress message back to the main thread. This includes the progress percentage and the name of the file. Here I’m using int.MinValue to differentiate the first progress message from subsequent ones. This sentinel value means that the main thread doesn’t have to maintain any state to handle progress messages.

I mentioned above that this function handles errors, but you don’t see any error handling code! Any errors that occur from opening the file, or reading the data are signaled as exceptions. The BackgroundWorker class will catch these and pass them back tot he main thread. I just love this – it keeps the code here very clean.

Note the using statement on line 11. It is important to do this when using file I/O objects so the underlying OS objects get cleaned up correctly. See this for more information.

The progress percentage value is computed very simply, the code simply keeps track of the file position as a ration to the file size. This is the obvious part.

Note line 30 – this is very important. It only sends progress messages to the main thread when the value changes – not for every line, which would be quite expensive (give it a try to see).

The entire AsyncFileLoader.cs file is not very big, only 29 lines of actual code and is very straightforward.

The code in the main thread to mange the UI is equally straight forward and consists of just a single event handler attached to the open button’s click delegate. This one function does all of the following:

Gets the file name from the user using the open file dialog.
Maintains the UI state, disable buttons, showing/hiding the progress bar, displaying messages, etc.
Creates a the AsyncFileLoader object
Starts the asynchronous file loading operation
Handles progress messages
handles the completion of the operation
Handles errors.

   1: private void OpenAFile_Clicked( object sender, RoutedEventArgs e )

   2: {

   3:     try {

   4:         OpenFileDialog ofd = new OpenFileDialog();

   5:         ofd.CheckFileExists = true;

   6:         ofd.DefaultExt = "txt";

   7:         ofd.Title = "Open an text File";

   8:         ofd.Filter = "Text|*.txt";

9:

  10:         OpenAFile_Button.IsEnabled = false;

11:

  12:         ofd.ShowDialog();

13:

  14:         if ( ofd.FileName.IsBlank() ) {

  15:             OpenAFile_Button.IsEnabled = true;

  16:             return;

  17:         }

18:

  19:         AsyncFileLoader TheLoader = new AsyncFileLoader();

20:

  21:         //---- Do this when the progress bar is updated

  22:         TheLoader.ProgressChanged += ( Sender, ArgsX ) => {

23:

  24:             if ( ArgsX.ProgressPercentage == int.MinValue ) {

  25:                 Cancel_Button.IsEnabled = true;

  26:                 Cancel_Button.Click += TheLoader.PerformCancel;

  27:                 OpenProgress_ProgressBar.IsEnabled = true;

  28:                 OpenProgress_ProgressBar.Visibility = Visibility.Visible;

  29:                 OpenProgress_ProgressBar.Value = 0;

  30:                 Info_TextBox.Text = ArgsX.UserState as String;

  31:             }

  32:             else {

  33:                 OpenProgress_ProgressBar.Value = ArgsX.ProgressPercentage;

  34:             }

  35:         };

36:

  37:         //---- Do this when the background worker is completed

  38:         TheLoader.RunWorkerCompleted += ( SenderX, ArgsX ) => {

39:

  40:             RunWorkerCompletedEventArgs args = ArgsX as RunWorkerCompletedEventArgs;

41:

  42:             if ( args.Error != null ) {

  43:                 PopErrorDialog( args.Error, "Cannot process file!" );

  44:             }

  45:             else

  46:             if ( args.Cancelled ) {

  47:                 Info_TextBox.Text = "Loading cancled";

  48:             }

  49:             else {

  50:                 Info_TextBox.Text = "File Loaded";

  51:             }

52:

  53:             Cancel_Button.IsEnabled = false;

  54:             Cancel_Button.Click -= TheLoader.PerformCancel;

  55:             OpenProgress_ProgressBar.IsEnabled = false;

  56:             OpenProgress_ProgressBar.Visibility = Visibility.Hidden;

  57:             OpenAFile_Button.IsEnabled = true;

  58:         };

59:

  60:         //---- Start the ascynrnous file loading operation

  61:         TheLoader.RunWorkerAsync( ofd.FileName );

  62:     }

  63:     catch ( Exception Ex ) {

  64:         PopErrorDialog( Ex, "General Failure!" );

  65:     }

  66: }

Functional programming is key to making this code clean and straight forward. Here we’re using lambda functions connected to the AsyncFileLoader’s progress and completion events.

You can see in the progress changed handler how no state needs to be kept – this lambda function gets all the data it needs from the event. You can see how the sentinel value (int.MinValue) is used to trigger the change in UI state.

Completion is handles in a similarly manner and resets the UI state. This lambda also handles any errors thrown by the loader by checking the args.Error member which will reference an exception if one was thrown.

This is a great example of using multi-threaded programming for something other than speeding up a computationally bound algorithm using parallelization. Some may suggest that this isn’t “real multi-core” programming, but it is. Indeed, the developer doesn’t need to know how to implement complex inter thread communication or synchronization, but just because this isn’t hard, doesn’t mean it isn’t real multi-threaded, and multi-core enabled code. It absolutely is and the developer does need to understand asynchronous programming techniques to use it.

Using the BackgroundWorker class is a very simple straight forward way to enable your programs to be more responsive, and to leverage multi-threaded and multi-core performance. You can use other managed code techniques such as threads and dispatching for more sophisticated work.

del.icio.us Tags: performacne,programming,C#,multi-core,multicore

You can find the complete VS 2008 project in the attached ZIP file.

Beyond Hello World - Update 5, TreeMap Control Working, Perf Issues

rgr — Sat, 24 Mar 2007 21:03:00 GMT

CLCV V5 now has a fully working TreeMap control that zooms, supports mouse over events and looks pretty good. The regions are laid out with the Squarified TreeMap algorithm. Even better, the tree map itself scales to large numbers of nodes - easily 100's of thousands, and on my lap top, it will handle a couple of million nodes relatively well. But there are two major performance problems: 1) WPF rendering seems to be very expensive. 2) Tree Map nodes are relatively expensive in terms of memory size. This limits the number of nodes to a ~2 million. You can find a link to the source code at the end of this post.

Note - all performance numbers (number of objects, times and profile data) are gathered from my new Acer Ferrari 5000 laptop.

From a memory usage perspective the control performs acceptably for even a few hundred thousand nodes. Tens of thousands of nodes are no problem. But, it does begin to struggle with about a million, with two million being a empirical limit. A future post on this WPF version of CLCV will focus on memory optimizations and usage in detail.

For this post, I'll focus on WPF rendering performance. In summary, the primary performance issue that limits the scaling of my treemap control isn't memory or CPU time to compute or render the layout - it is actual physical rendering of the rectangles and text by WPF itself. WPF cannot keep up with more than about 750 rectangles and a small number of scaled text items.

My treemap control is pretty well optimized (there is still some work to do) - but the computational performance of the control itself is not the limiting factor. The most important aspect of my treemap implementation is that it is smart about how much work it does -limiting its computations and rendering to only the nods that are reasonably large.

When learning about treemaps, I looked at some existing code and read all the web material I could find. It looks like most implementations are pretty basic - they compute the size and location of each rectangle for the entire tree. I thought this was a bit odd. It seemed to me that it would be more efficient to only process the part of the tree that would be visible - e.g. computing and rendering tiny or invisible rectangles didn't seem like a good design decision to me.

My first implementation took the straight forward approach as well. As I suspected, for larger trees - even those with a only a few thousands nodes, computing and rendering tiny rectangles was a waste of computation and rendering time. As you can see in the image to the right, rectangles that are smaller than some limit are too small to effectively mouse over or to meaningfully discern their relative area with respect to their parent.

So, I modified both the layout code and the rendering code to stop when the area of the rectangles became less than some threshold. This worked very well both from a visual perspective and performance standpoint. It also allows the data tree to become very large as it means that neither the layout and rendering costs grow with the overall tree size as the number of nodes surpasses the number of rectangles that the algorithm decides to actually render.

Experiment: CLC V5 includes a unit test for the treemap control that allows you to control the size of the three and set the treemap parameters such as the Area Limit.

The area limit is the minimum size of the rectangles that will be rendered. Assuming there are enough nodes, the larger this number, the fewer rectangles will be visible.

From empirical testing I determined that a value of 64 works pretty well.

For trees over a one or two thousand nodes, there are usually more nodes than can be displayed. In these scenarios, the scaling limitations are inherent to WPF itself, not the layout computations, or rendering in the treemap control.

Its important to understand how the control works and when WPF actually does the visible rendering. The treemap control has two main steps: the first is the actual layout computations of the tree, and the second is the rendering of the tree. Once the control is rendered, then WPF will take the rendering data generated in the control's OnRender function and actually turn that into DirectX commands that become visible on the screen. Its this third step that is the limiting factor.

The layout computations are handled by a function called ComputeAllNodeBoundingRects. This function starts at the root node and recursively computes the size of each visible rectangle for the nodes in the tree. This function stops its recursion when it reaches nodes that have visible areas less than the Area Limit. You can experiment with area limit values using the unit test (see above). If you set the area limit to zero, then the layout computations will compute a rectangle for every node in the tree.

Computing the bounding rectangles only needs to happen when the treemap control receives a new data tree (by setting the TreeMapData property), or when the render size changes (handled by the OnRenderSizeChanged event).

When WPF determines that a control needs to be rendered, it calls the controls OnRender method. This control's OnRender method recursively paints each of the rectangles computed in ComputeAllNodeBoundingRects. It also renders the text for the root nodes and first level nodes.

Both of these functions are relatively fast - here are some statistics for the initial random tree. LQ means 'lower quartile', UQ means 'upper quartile', IQ range is the inter quartile range divided by the median value. Range is the total range (max-min) divided by the median. Times are in milliseconds.

	Count	Min	LQ	Median	Mean	UQ	Max	IQ Range %	Range %
Compute	100	2.6	2.8	3.0	3.4	3.4	7.7	18.4%	171.7%
Render	100	5.8	6.2	6.7	7.3	7.7	19.6	21.8%	204.9%

These times are for computing and rendering from 1,316 to 1,539 visible nodes. As you can see from the times, neither compute nor rendering times in the control itself should inhibit the control from rendering smoothly. This is especially true when the control is rendering due to events other than size changes.

But, even with the times above, the control still struggles to render - you can see this by just rolling the mouse over the control and watching the lagging mouse-over node changes, or by resizing the control. In both cases, if the control is painting more than 700 rectangles or so, then it can't keep up.

While relatively anecdotal, the CPU utilization for the control also seems on the high side. Just continually moving the mouse over the control uses considerable CPU, 70 to 80%. This is high, especially considering that my lap top has a dual core AMD Turion processor with has a WinEI rating of 4.8.

While there does seem to be some material performance and scaling issues with WPF, there is a lot to like about the programming model. I'll talk about this more in subsequent posts.

Source Code for this post: CLCV-BLOG-5.ZIP contains the source code to this post. I didn't include the data files in this zip file as they haven't changed - you can simply use the ones from CLCV-BLOG-3.ZIP.

Beyond Hello World - Update 4, File loading 27 times faster!

rgr — Wed, 31 Jan 2007 02:16:00 GMT

CLCV V4 now loads files about 27 times faster than V3 when running on my laptop. The tree view is also about 5 times faster. This comes from changing my initial naive implementation to a smarter one where I minimize the inter-thread communication and handle the tree view much more efficiently. More information about the source code is at the bottom of this post. Here is what I learned in working on V4.

Updating WPF UI elements can be expensive for large numbers of items. An effective and simple strategy is to only load data into WPF UI elements that the user actually needs to see - don't use WPF objects as the store for large numbers of objects.
Updating pixels on the screen is expensive - even with relatively high performance hardware. Changing pixels (e.g. updating UI controls) at a rate faster than the monitor refresh rate is a waste of system resources, CPU time, GPU time, and memory bandwidth. UI updates that are related to (or driven from) high throughput tasks should be paced to no more than the monitor refresh rate.

V3 was the first functional version of CLCV and while it worked, it loaded files very slowly - talking 90 seconds or so (on my laptop) to load the largest data file (about 8.75MB in size). Given that the ultimate goal is to handle CSV files that hold data for the entire Windows Vista source code tree, I really needed to improve CLCV's performance.

The cause of the performance problem was easy to find using the Visual Studio 2005 profiler. I simply enabled instrumented profiling and the offending code was obvious.

The most time consuming operation in V3 wasn't the actual file read time, it was the overhead of building the tree of tree view items. In V3, the file reading thread sent a message to the UI thread for every new file and directory from the CSV file. The UI thread then added that information to the tree of tree view control items as the file was read. This was very time consuming and took much longer than actualy reading the file.

It turns out that building a tree of tree view items is simply expensive. The most expensive part being setting the string that is displayed as the item's header. This is closely followed by actually making a new item the child of another (ItemCollection.Add). I don't yet know why this is expensive, only that it is. It may be because I'm building the tree bottom up instead of top down - Kiran Kumar discusses this as a potential issue here. I need to chat with my friend Tim Cahill the WPF performance guy about this a bit more.

For V4, I took a different approach: I re-factored the code so the file loading thread now does all the work of constructing a tree of objects that represent the original directory structure and its files. I also moved the logic that updates the progress bar from the UI thread to the file loader thread - only sending progress messages to the UI thread every 33 milliseconds (this is configurable).

The results were dramatically better. The file loader thread could read the file and re-construct the directory tree much faster than the previous version. On my laptop, the 8.75MB file could be loaded in about 1.47 seconds - not bad at all. In this version, the file loader thread sends a message to the UI thread to update the progress bar no more frequently than every 33 milliseconds (about 30 times per second). This is more than often enough so that the progress bar is visibily smooth, but not so much that updating the progress bar takes too long.

Experiment: Updating the progress bar is expensive - way to expensive to do this for every line read from the file. You can see how expensive this can be by using CLCV V4 and setting the "Progress Update Interval" in the options dialog box to 0. When this is zero, the file reading thread will send a message to the UI thread for every record read from the the CSV file. The messages get queued up in the UI threads dispatcher object and processed as fast as the UI can handle them. Processing all these messages and updating the progress bar takes a much longer time than processing the entire file! The lesson here is that the overall process of updating the UI (chaning pixels on the screen) is simply expensive. There is really no need to update the UI faster than the monitor refresh rate. Often about 1/2 to even 1/3 of the monitor refresh rate is just fine.

Note that for most things, a UI update rate of 30 or so updates per second will present a smooth animaition to the user. If needed, updating the UI faster -- at or close to the monitor refresh rate -- will work well.

Next, I needed a strategy for minimizing the costs of building the tree of tree view items that display the directory tree and files. Given that the file reader thread builds a tree structure, the solution was simple: CLCV V4 only populates the tree view control when it needs to, and only populates the items the user needs to see. After the file is loaded, the UI code updates the tree view with the top level elements. When the user expands an element, the UI thread then populates the data for that item's children.

In this way, CLCV only pays the costs for populating elements the user needs to see; only tree view items that will actually be displayed are created and added to the tree view item tree. This also amortizes the costs of the items displayed over the time the user actualy minipulates the control. So even if the user browses the entire three, he never experiences a sluggish tree view control.

Experiment: This works quite well, if you use CLCV version 3 to load the large test file (test-l.clc.csv) the first click on the bottom entry ("GSFD") will take a noticeably, and annoyingly, long time to expand ( about 2.5 seconds on my laptop). With V4, this happens quickly: it takes about 150ms to populate 922 child items (~6,000 items per second, or ~166us). It looks like it takes about anothe r300 milliseconds to draw the new items: its hard to measure this because WPF doesn't have a begin and ending events for item expansion (I just used a stop watch).

With V4, the profiler shows a very different picture: The bulk of the CPU time during file loading is spent actually parsing the text data from the file, primarily converting text fields to decimal values using UInt32.TryParse().

This is as expected. It probably isn't worth optimizing the conversion operations by writing a hand crafted text to Uint32 conversion routine as such a routine would need to handle localization and othe rissues. I expect it would only result modest performance improvements. The primary file loading bottleneck in V4 isn't CPU time, but I/O efficiency.

Loading a 8.75MB file in 1.47 seconds is pretty good - its about 6 MB/s; and its plenty fast enough for my intended scenario. But, it is still slow compared to other applications. I've developed other tools (such as CLC itself) that are completly I/O bound and use only one thread for the entire application. These tools easily drive the disk at its maximum sequential read rate of about 35 MB/s while handling much more complex string opeations than merely parsing some CSV data. For example, CLC is an order of magnitude faster than CLCV. The reason is the stream reader class - it doesn't do asynchronous or un-buffered I/O and its paying the cost of transcoding ANSI or UTF8 text into UTF16 for storing in .NET string objects.

In contrast, my natively implemented tools read files fully asynchronously in un-buffered mode. This makes I/O operations happen in paralell with data processing - not sequentially. They also parse the text data directly from the buffers populated by the operating system file read operation - no data copies are needed. Next, they handle ANSI and UNICODE directly - they don't transcode all input text to UTF-16.

Now this isn't to say that the StreamBuffer class is slow - it isn't. Using off the shelf I/O libraries in native C++ results in comparable performance to the .NET StreamBuffer class. The difference comes from using hand crafted I/O routines specificaly designed to for sequntial text line reading and maximizing parallism between disk I/O and computation.

One of my future tasks is writing a COM wrapper for my hand crafted C++ I/O libraries so they can be used efficiently from .NET languages. I expect this will allow CLCV to come very close to the file read performance of my native tools.

Source Code for this post: CLCV-BLOG-4.ZIP contains the source code to this post. I didn't include the data files in this zip file as they haven't changed - you can simpy use the ones from CLCV-BLOG-3.ZIP.

Beyond Hello World - Update 3, Control Templates, Multithreading, and more... (with source)

rgr — Mon, 22 Jan 2007 04:58:00 GMT

I've learned a lot in working on my first real WPF application such as implimenting multi-threaded file reading, how to use the dispatcher object, how to use control templates to customize controls, the basics of application configuration, using abstract C# classes, and using anonymous methods.

I've posted the source code that goes along with this post. It is in the file CLCV-Blog-3.ZIP at the end of this post. This version of CLCV has some new features

It has an option dialog box for setting the user's preferences. This mechanism uses the application properties wizard in Visual Studio - this was surprisingly easy to do, but it does have one problem; I can't control where the data is saved! (yet).
File I/O is multi-threaded. One thread reads the lines from the CSV input file and sends the resulting data to the UI thread using the UI's Dispatcher.
File reading can be quickly canceled - an important attribute for a program that is designed to load large files.
CLCV displays an accurate progress bar as it loads the file.
The recently used file list now works correctly

It discards files that no longer exist when CLCV starts
It keeps the list sorted in order of use (most recent at the top).

There are many new concepts for a native C++ developer to learn when ramping up on WPF and C#. One of the most important is how to customize the look and feel of your applications - this is a Raison D’être for WPF. In my earlier versions of CLCV, I couldn't figure out how to customize the look and feel of buttons so I rolled my own using a rectangle and some animations. It looked ok, but this was completely the wrong way to go about it.

One of my friends (Joe Laughlin) pointed me in the right direction: Customizing controls is easily done using Control Templates which are designed to do exactly what I needed: completely controling the look and feel of any WPF control while maintaining their semantics. Even better, with WPF resources, this can be asily done for an entire application. Control templates made it stright foreward for me to set the look and feel of buttons in my application to a blue colored theme. So far, I've just scratched the surface of control templates, but you can see what I did by looking in resources\button.xaml. It is tied into the application in App.xaml like this:

    <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="Resources\Button.xaml" />
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </Application.Resources>

The XAML above applies my customized Button control template to every button in the application without touching the XAML for the other windows or pages. This is very cool. More than cool, its a great example of how WPF separates design (look and feel) from an application's semantics.

An important feature of CLCV V3 is its options dialog box. This makes it easy to tweak and tune key parameters without recompiling. Here is some info on the options:

Show Console: when checked, CLCV will display its debug/diagnostic console.
Synchronous Line Reads: this forces the file reader thread to post messages to the UI thread synchronously using Invoke() instead of BeginInvoke(). ( using Invoke()this is slow)
Animate Directory Loading: when checked, this forces CLCV to visibly populate the tree view control as items are read (this is slow).
Maximum Outstanding Messages: this is the maximum number of outstanding messages the file reader thread will have with the UI thread.
Message priority: this is the DispatcherPriority used by the reader thread send messages to the UI thread (in the calls to Invoke() or BeginInvoke().

While V3 of CLCV is still naively implemented in many regards (this is my first WPF app and I only started with C# and WPF in late December '06). But, I knew from the get go that I'd have to handle file reading in a thread separate from the UI thread to avoid UI hangs and sluggishness during file loading.

Of course, it is possible for single threaded applications to efficiently read files and keep their UI responsive - I have a native C++ class that provides I/O support for this. My native class is extremely efficient and can easily drive the disk at its maximum sequential read rate with one thread. But, this is more complex in .NET 3.0. While .NET does provide the fundamental support for asynchronous I/O, I'd essentially have to re-implement my Native C++ classes in C# and I'm not ready for that yet.

This approach would also be just as messy in WPF as it would be in native code: mixing I/O and procssing UI events in one thread requires a state machine approach to handle issuing asynchronous reads, processing UI messages, and handling completed read events. This is prone to complexity and can be difficult to debug and maintain.

Fortunately, it is very easy to create a file reading thread in .NET and for that thread to send its data to the UI thread asynchronously. It takes surprisingly little code to do this:

   1:          public FileLoader( DataViewWindowClass dvw )

   2:          {

   3:              MyDataViewWindow = dvw;

4:

   5:              UseSyncronousLineReads      = TheApp.UserProperties.SyncronousLineReadsFlag;

6:

   7:              StartFileLoadHandler       += MyDataViewWindow.StartFileLoad;

   8:              NewFileHandler             += MyDataViewWindow.AddNewFileHandler;

   9:              NewDirHandler              += MyDataViewWindow.AddNewDirHandler;

  10:              NewDirTreeHandler          += MyDataViewWindow.AddNewDirTreeHandler;

  11:              FileCompletedSignalHandler += MyDataViewWindow.FileCompletedSignal;

12:

  13:              FileLoaderThreadEntryPoint  = new ThreadStart( LoaderThread );

  14:              MyThread                    = new Thread( FileLoaderThreadEntryPoint );

  15:              WaterMarkSemaphore          = new Semaphore( TheApp.UserProperties.MaxOutstandingMessageCount,

  16:                                                           TheApp.UserProperties.MaxOutstandingMessageCount );

  17:          }

The code above is from DataView.Xaml.cs. It creates the FileLoader object which owns the file reading thread. The reading thread uses five delegates to communicate with the UI thread:

One to signal that the file loading operation has actually started. This message is used to send the file size to the UI thread so it can setup the progress bar.
One message each for for files, directories, and directory trees. Each of these messages also includes the number of bytes read from the file so far. This allows the UI thread to keep the progress bar up to date.
And finally, one to signal that the file read is completed.

The reading thread does all the work to read the file, which is in comma separated value (CSV) format. The CSV file contains all the data necessary for CLCV to reconstruct the directory tree scanned by CLC. (note, in the TestData directroy from ZIP file, I've included three CSV files, one small, one medium sized, and one large - this is actual data from some of my source code trees).

The reader thread handles the following work

file reads using a StreamReader object
detecting header lines and blank lines
splitting each line into the comma separated fields
parsing and converting the text data to binary data and putting that data in objects
sending those objects to the UI thread

All in all, this works quite well for a first attempt: the UI stays alive (doesn't hang), the file read operation can be quickly canceled, and its all done with straight forward code.

Note that getting the dispatch priority correct is very important. On a single CPU system (like my laptop), using too low a priority simply causes the entire process to drag out. Using too high a priority causes the I/O thread to starve the UI thread. For example, if you set the dispatch priority to "input", then the UI thread may need to work through large numbers of input messages before it processes input events, such as a cancel request. Setting the dispatch priroity above "input" (to "loaded" or "render") will keep input events from being processed.

Going higher, to "render" will interfere with the actual rendering of the UI causing the progress bar to be jerky. Going higher than "render" to "databind", "normal", or "send" completly stops UI rendering and blocks all input thus hanging the UI; this is specific problem that multi-threaded I/O is intended to handle.

The "Background" dispatch priority seems to work acceptably well. Using this priority, the UI remains responsive while consuming input events fromt the reader thread relativly smoothly.

Note that using dispatcher priorities is orthogonal to setting thread priorities - the dispatcher priority is simply the priority at which the dispatcher removes input events (delegates) from its input queues.

But, there are some performance issues in this initial naive implementation:

The progress bar doesn't terminate nicely - it gets updated to 100% complete in the UI file completion routine (see the function FileCompletedSignal() ), but WPF spends a lot of time in this function before it re-renders the UI. I need to figure this out.
The biggest problem is the time it takes to actually build set of tree view items that are used to populate the list of directories and files. This takes 10 to 20 times more than the actual file I/O, which is very surprising given that in native code, I have tools that do significantly more text processing while still remaining I/O bound - all in one thread.

The performance of the tree view control itself also bogs down with the largest file. Its noticeably sluggish when the selection changes.

That being said, my first implimention is certainly naive - I simply build a set of tree view items that mirror the entire file and directory structure. It doesn't look like too much trouble be a lot smarter about this - populating the tree view as needed from another data structure. I'm going to try this next.

In upcoming posts, I'll explore better ways to handle the TreeView control (only populating it as necessary), do some profiling to see if I can speed up data processing, and add some more advanced control templates, and explain why its important to throttle the number of messages from the file reading thread (a producer) to the UI thread (the consumer).

Beyond Hello World - An Update On My First WPF Application (with source)

rgr — Thu, 04 Jan 2007 02:28:00 GMT

I've been working on my first useful WPF application and I've learned several things since my last post and answered a few questions. I've included a ZIP file with my updated source (you can find it at the bottom of the post, it includes full Visual Studio 2005 project) Here is what I've leaned:

How to create wrapper functions for native Win32 interfaces.
How to create a console window and direct the output to the Trace and Debug classes to the console window.
How to create an animated button using a rectangle, styles, and a storyboard - all in XAML.
How to close a WPF Window object.

(1) Of course it is possible to write a WPF or managed application without calling Win32 APIs. But that can sometimes be limiting as there is functionality provided by the Win32 APIs that are not available via .NET classes. The WIn32 console classes are a good example: .NET provides the Console class, but no methods for actually creating or manipulating the console window itself.

I knew from talking to others that calling native API's should be easy and I found a few examples of this using marshaling.   However, the examples didn't work for some of the APIs I needed.   So, I emailed the internal .NET development alias with a couple of questions. It turns out that calling native Win32 APIs is really, really easy - much easier than some of the examples on the web. You can see how to do this in the Win32API.CS file.

Here are a few things to note in this file:

There are no explicit marshaling statements.  When declared correctly, the C# compiler generate the interfaces correctly.

Note that the output parameters that need a pointer to a structure are simply declared using the 'ref' statement.   A .NET class would have worked here as well, but value objects (structs) seemed more appropriate.

You should use IntPtr as the type for handle - these are compatible with the safe handle classes.

Note the use of types like UInt32 and UInt16 which mirror the standard Win32 data types.

(2) I learned how to use the trace and debug classes with a console window from the application itself. CLCV now creates its own console window and uses the ConsoleTraceListener class to direct all the output to the Trace and Debug classes to the console window. This was a bit tricky as I needed to interface directly with some low level Win32 APIs.   To do this, I created two wrapper classes called K32 and U32. These classes provide the data structures and interfaces necessary to call into the Kernel32 and User32 DLLs respectively.

With these interfaces, its straight forward to create a console, open up the CONOUT$ handle to activate STDOUT, then set the size of the console window to 50 lines and 132 columns (the default is a bit small). This is really handy - it allows me to see the trace and debug output without using any other applications.

I'll update CLCV to make this console window optional in the future using a configuration dialog and possibly a hidden control.

(3) The WPF Button object is nice, but it controls its own behavior when it gets the focus - there is no way to control this. So, I decided I wanted a spiffier close button on my main window.   After about three hours of reading documentation and experimenting, I developed used a Rectangle object to build a nice close button with a mouse over animation. This was a little tricky because the Rectangle object doesn't support the IsMouse over property, it only supports MouseEnter and MouseLeve. This mean I needed to animate both events.

The outcome was pretty nice even though I'm a pretty poor UI designer (check it out!)

(4) Doh! Sometimes things are so simple. The code in the previous post simply used the red X button in the window frame to close the app because I couldn't find the event or message to close the window.   I was trying too hard!   Closing a WPF window object is trivially easy - just call its Close() method.

I continue to be surprised with how easy many things are with WPF and .NET. For example, the animated close button would require large amounts of relatively complex code in C++. With WPF, the animation itself took zero C# code and 33 lines of simple XAML code. With even a basic understanding of XAML (which is what I currently have), the code for the button is straight forward and easy to understand. I believe that anyone who is proficient in HTML could understand what is happening without know XMAL.

I'm really starting to see how XAML is a great bridge between designers and developers - while it can be complex, its straight forward enough to be understood by people who are not developers.

Of course, all this simplicity comes at a price - the XAML and .NET run times are not free - they can have significantly more computational overhead and memory usage than native code. That being said, it seems like a reasonable price to pay for many types of applications and (like many technologies) they will get more efficient over time.

Notes on the source code

This update includeI some very nicely implemented class from Sven Groot (Ookii.org) that make it easy to use the Vista style common file dialogs for .NET 2.0 (version 1.2). You can get the full package here.
I've included a "testdata" directory along with the source code that contains empty files. Thiles files all have the ".clc.csv" suffix. This is what the CLCV applicatoin looks for.

Beyond Hello World - My First WPF Application (with source)

rgr — Sat, 30 Dec 2006 23:49:00 GMT

My pet project for the holiday vacation has been writing a WPF application to view data from my code line counting tool CLC.EXE (soon to be released on Codeplex). CLC produces counts of lines, code, comments, and other statistics per file, per directory and for entire directory trees. When complete, the CLC data viewer (CLCV) will read a CLC data file and display various visualizations of the data such as a tree map (see also, and also), some pie charts and perhaps a histogram or two.

I’ve included the first working CLCV application shell in the attached zip file. This project builds in Visual Studio 2005 (any version). I used Microsoft Expression Blend to design the UI. The app-shell currently implements the application’s initial UI panel which gives the user the opportunity to open a new file, or select a recently opened file. This panel has the following features:

It keeps track of the most recently opened files, keeping the sorted with the most recently opened file at the top. It also manages the list

When CLCV starts, it deletes any files from the list that no longer exist
When the user clicks on a file name that no longer exists, the name is removed from the list and the user is notified with a simple message box.

It uses XML serialization to save the recently opened file list.
It saves the recent file list in the users application data directory (not under My Documents)
When running on Windows Vista, it uses the new file open dialog box.

Note, to do this I used a really nicely implemented class from Sven Groot (Ookii.org). See his Vista style common file dialogs for .NET 2.0 (version 1.2) here.

I still have few things to do for CLCV’s initial UI panel:

The main UI needs a close button, but I haven’t yet figured out how to close a WPF window.
The main UI panel needs to remember its position – currently it always appears in the center of the screen.
For native applications, I usually create a console window for simple debug spew, but this doesn’t seem like the “.Net Way”. I need to figure out how to effectively use the Debug and Trace classes. For example, how do I get the debug and trace output when I’m not running the tool under the VS debugger?

This is my very first foray with both WPF and C#. My only material exposure to managed code has been some utilities written in managed C++ so I could use the excellent Dundas Charting products. I used managed C++ because I was in a hurry and needed to leverage my existing class libraries (this worked well).

So I was pleasantly surprised that getting the UI shell and initial UI panel up and running was astonishingly easy to do; especially given that I could barely spell WPF and C# a week ago. The most amazing thing to me is how little code was needed is to do all this; 161 lines of C# code and about 80 lines or so of XAML. This is probably at least an order of magnitude less code than it would take to do all this in native C++, even with a nice class library like WTL and ATL. Not only is it less code, it was also easy to do – the compile-test turnaround time is super fast and the VS environment and debugger has deep knowledge about the C# language and .NET class libraries. Intelisense is really helpful and saved me loads of timing having to go back and look at documentation. VS’s C# editor is also quite good at finding syntax errors without compiling, saving more time.

I'm sure that someone will point out that even doing this right on top of Win32 in C could be done in a small amount of code. I'm confident that is true in a limited way - but doing this with Win32, or even WTL/ATL would be a lot more code to get the same app behavior and features that are inherent in a C# and WPF application: the blended background, the nice use of fonts and colors, transparent controls, the nice use of animation to highlight focus, the flow and layout capabilities that let windows be resized and maintain a useable and attractive layout.

It took me about 15 minutes to develop a nice look and feel for the initial UI panel in Blend. There is simply no comparison here for native UI code - its all done by hand! The ability for UI designers to work efficiently with developers is a revolutionary capability.

There are other things I like about WPF and .NET as well:

The WPF controls, their properties, methods, and events, seem much consistent and coherent than those from Windows.Forms.
Microsoft Expression Blend is really easy to use and looks like it will be a great tool even at V1.0.
If you use Blend to start Visual Studio, they work nicely together.
I like Intelisense with native and managed C++, but wow, it sure is awesome with C# - the editor and dev environment know WAY more about C# than they do C++.
I really like how well the XAML code and the C# partial classes fit together: The C# code can simply reference objects defined in XAML by their name which is defined by the “x:key” attribute.

I did run into a few issues though:

Blend is a memory HOG. My system has 1GB of memory and running dev studio and blend together often cause a lot of paging.

The idea behind XAML is great, but I think the implementation in XML is clunky. It seems that every new thing at Microsoft uses XML. Is that always the right choice? Does a having a good hammer make every problem a nail?
Data binding is still confusing to me…. It sure seems complicated, but I suspect that I just need to work on groking it…
There is a TON of documentation on WPF, .NET 3.0 etc, but I still find it difficult to figure out how to do simple things.

For example, I needed a simple way to save and restore the recently used file list. The .NET Configuration class seemed like a good place to start. I spent about two hours dorking around with the Configuration” class before I gave up. It and its related classes are way too complicated and the examples were SuperCrapy™. So, I tried XML serialization. It took me about 15 minutes to get the save and restore functionality working – nice… J
There seems to be a lot of name space overlap between .NET 3.0 (WPF) and Windows.Forms. Of course, this is why we have namespaces! But, the MSDN docs don’t really make it clear at the top level what is what – everything is under the class library hierarchy.

Glork! Why in the heck do the .NET classes not support the new vista dialog boxes??? While Sven Groot’s classes are really handy (and nicely implemented), I shouldn’t have had to use them. Am I missing something? Is Sven missing something? Perhaps so…

It is important to note that the benefits of WPF, C#, and managed code in general come with costs. These applications are by their very nature larger in terms of memory and CPU utilization. Our experience on the client performance team is that it takes a lot of work to ensure that a managed application launches quickly, remains responsive to user interactions, performs well in terms of throughput, scales well to large data sets, and is a "good citizen" in terms if system resource utilization.

Good performance for managed applications is certainly possible, but developers need to be aware of the costs associated with managed applications, design for performance up front, and use performance tools (such as logging and profiling) to maintain good performance during the development process.

WPF Styles

rgr — Wed, 27 Dec 2006 11:36:34 GMT

One of the things I planned to do this holiday season was spend some time learning about Windows Presentation Foundation (here is the Microsoft link).

The first thing to did was write a "Hello World" program. I wanted just a simple window with a text box that said "Hello World". It was easy - Expression Blend and Visual Studio 2005 worked seamlessly together: it took about 5 minutes to get a basic "Hello World" program running - cool! It was relatively attractive and I set the background brush of the text box to Null so that it was transparent, giving the appearance of the text floating on the gradient background of the window.

I decided I wanted my little text box to change color when the mouse hovered over it. Then the WPF learning curve started to kick in. Ah ah! XAML styles and triggers are the answer....

My first attempt was the following ..... bbzzzzzz..... it didn't work... mmmmm

   1:  <Window

   2:      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   3:      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

   4:      xml:lang="en-US"

   5:      x:Class="HelloWorld.MainWindow"

   6:      x:Name="TheMainWindow"

   7:      Title="RGR's First WPF App"

   8:      Width="640" Height="480" ResizeMode="CanMinimize"

   9:      xmlns:Microsoft_Windows_Themes="clr-namespace:Microsoft.Windows.Themes;assembly=PresentationFramework.Aero">

10:

  11:      <Window.Resources>

  12:          <Style TargetType="TextBox">

  13:              <Style.Triggers>

  14:              <Trigger Property="IsMouseOver" Value="true">

  15:                  <Setter Property="Background" Value="#FF071D43" />

  16:              </Trigger>

  17:              </Style.Triggers>

  18:          </Style>

  19:      </Window.Resources>

20:

  21:      <Window.Background>

  22:          <LinearGradientBrush EndPoint="1,0.5" StartPoint="0,0.5">

  23:              <GradientStop Color="#FF0E0C0C" Offset="0"/>

  24:              <GradientStop Color="#FF661212" Offset="0.207"/>

  25:          </LinearGradientBrush>

  26:      </Window.Background>

27:

  28:      <Grid x:Name="LayoutRoot">

  29:          <Grid.ColumnDefinitions>

  30:              <ColumnDefinition Width="*"/>

  31:          </Grid.ColumnDefinitions>

  32:          <TextBox Margin="8,8,8,0" x:Name="HelloTB" VerticalAlignment="Top" Height="64"

  33:                   BorderBrush="{x:Null}" FontSize="36"  Foreground="#FF7E6E6E"

  34:                   IsUndoEnabled="False" Text="TextBox" TextWrapping="NoWrap" ToolTip="Text Box"

  35:                   BorderThickness="0,0,0,0" IsReadOnly="True"

  36:                   Background="{x:Null}"/>

  37:      </Grid>

  38:  </Window>

After some dorking around, it finally dawned on me what was wrong - styles are hierarchical. The style trigger was indeed working, it simply wasn't overriding the Background="{x:Null}" attribute of the TextBox as it has a higher precedence than the style in the trigger. The following example worked nicely: Note that on line 13, the Null background characteristics is specified in the style, and not directly in the attributes of the TextBox itself. This allows the background "Setter" in the IsMouseOver trigger to work correctly as it and the default background have the same precedence.

   1:  <Window

   2:      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   3:      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

   4:      xml:lang="en-US"

   5:      x:Class="HelloWorld.MainWindow"

   6:      x:Name="TheMainWindow"

   7:      Title="RGR's First WPF App"

   8:      Width="640" Height="480" ResizeMode="CanMinimize"

   9:      xmlns:Microsoft_Windows_Themes="clr-namespace:Microsoft.Windows.Themes;assembly=PresentationFramework.Aero">

10:

  11:      <Window.Resources>

  12:          <Style TargetType="TextBox">

  13:              <Setter Property="Background" Value="{x:Null}" />

  14:              <Style.Triggers>

  15:              <Trigger Property="IsMouseOver" Value="true">

  16:                  <Setter Property="Background" Value="#FF071D43" />

  17:              </Trigger>

  18:              </Style.Triggers>

  19:          </Style>

  20:      </Window.Resources>

21:

  22:      <Window.Background>

  23:          <LinearGradientBrush EndPoint="1,0.5" StartPoint="0,0.5">

  24:              <GradientStop Color="#FF0E0C0C" Offset="0"/>

  25:              <GradientStop Color="#FF661212" Offset="0.207"/>

  26:          </LinearGradientBrush>

  27:      </Window.Background>

28:

  29:      <Grid x:Name="LayoutRoot">

  30:          <Grid.ColumnDefinitions>

  31:              <ColumnDefinition Width="*"/>

  32:          </Grid.ColumnDefinitions>

  33:          <TextBox Margin="8,8,8,0" x:Name="HelloTB" VerticalAlignment="Top" Height="64"

  34:                   BorderBrush="{x:Null}" FontSize="36"  Foreground="#FF7E6E6E"

  35:                   IsUndoEnabled="False" Text="TextBox" TextWrapping="NoWrap" ToolTip="Text Box"

  36:                   BorderThickness="0,0,0,0" IsReadOnly="True" />

  37:      </Grid>

  38:  </Window>

One thing I did find frustrating - especially as someone accustomed to native code development (I can barely spell ".NET") is how easy it is to hork up the XAML so that the resulting executable crashes. For example, this little code fragment crashings Hello World nicely...

<Setter Property="Background" Value="x:Null" />

The buggy code compiled just fine in both Visual Studio 2005 and Expression Blend Beta-1. But when the Hello World program ran, it simple crashed. Even more bothersome was the fact that the VS2005 debugger was useless. When the program crashed, it popped up a useless dialog box with the wrong information. The bug is simple, there are no curly braces "{ }" around the x:Null. The correct snipit is:

<Setter Property="Background" Value="{x:Null}" />

This isn't too surprising given that the task of processing the XAML code into a .NET object model is multi-step, happens at run-time and is complex. Given that XAML, WPF and the related technologies are so new, its amazing that the tools work as well as they do. The caveat here is that don't expect as robust a development and debugging environment with XAML that we enjoy with native C++, Managed C++ or C#. It will take some time (Orcas??) but the Dev Div folks will get there!

My next task is to make a program that does something useful. I have a program that counts the lines of code in various languages (C++, C#, Perl, batch files, assembly language, etc). I planto build a WPF program that displays a tree map of line counts for the entire Windows Vista code base..... We'll see how WPF scales with this one.