Awkward Coder

My last post had a comment from @LordHanson about changing the thread priority via the ThreadStart parameter to see if this improved the performance. I made the following small change to include setting the thread priority: This improved the responsiveness of the UI when the number of thread is equal to or greater than the number of logical processors (tested with 2 * System.Environment.ProcessorCount), I still see the UI stuttering & stalling occasionally but it's greatly reduced - happens less than 10% of the time. I then start to wonder is it better from the point of view of total time taken to reduce the concurrency to less than the number of logical processors or to reduce the thread priority. I suppose the answer depends on which technique you want to use, for me there isn't a justifiable reason not to use the Parallel.For from the TPL - it's not a piece of time critical code.

I was wondering on the affects if my previous post was re-written to remove the use of TPL and just use the standard threading classes in the framework instead, would the performance be different. So the previous post was using the following code: When the limited concurrency scheduler is initialised with a number greater than or equal to the number of logical processors then the CPU hits 100% and the app stalls and stutters. If this is re-written without the use of TPL would I get the same results? Re-writing this produced the following code, using a Semaphore to control the number of concurrent threads: In answer to the question, you get exactly the same behaviour, there is no benefit in not using TPL to handle the concurrency - good :)

I've been working with a team where I've been putting a WPF UI over a set of implementations of a custom interface. Each implementation is a long running process which is handled in standard manner by creating an asynchronous Task<T> and displaying the results from the continuation. The standard CPU utilisation for the majority of the interface implementations is shown below - this represent the ideal, not hogging the CPU's and behaving like a good citizen... Where as one implementation has the following CPU utilisation - all logical processors max'ed out. The app becomes unresponsive, the UI starts to stutter and freeze all because the dispatcher (UI) thread is not being scheduled frequently enough - white screen of death (WSoD). It's not only this app it starts to affect but all other apps running. Hopefully the difference between the majority and this particular instance is obvious - the majority are single-threaded long running processes and t...

I've been looking at writing an exercise app, and this would require some kind of units of measure for distance (as well as time). I could use an enum to represent the different types of units - metres, kilometres, yards, miles etc. But this seems to be lacking from the point of view of converting between the different types - I would need a class to represent the conversions. What I want is a more integrated approach - the use of static read-only properties. What I want to be able to do is best described by the following test: The Measurement struct is very simple, a couple of properties - Amount & Unit and a ConvertTo method: As you can see in the ConvertTo method the Unit class owns the conversions - it is more than just a simple Enum - it has behaviour, how to convert between the different units of measure. So how are the units defined? A Unit instance is exposed as a read-only static property on a static Units class: What makes this approach interesting ...

This is the final post in this mini series, I'm going to show the finished UI user control and how simple it is to host inside a WPF app. The code is available on gitHub  and the published binaries are available via nuGet  (supports .Net version 4.0+). Before I show the finished UI, lets look at the F# Interactive in Visual Studio, this loads, queries & displays the results from an external assembly: What does this look like in my implementation? It's looks pretty familiar right? :) The major difference is I've output the working folder for the F# interactive process when the process starts: I've made this configurable in code, so I thought it would be a good idea to tell the end user where they could put any assemblies they want to reference. How can the user access the working folder? Simply, a right click menu: All the menu options should be obvious, the working folder for the above example is shown below, you can see it has the assembly re...

Having just published Simple.Wpf.Terminal as a nuget package I wanted the ability to skin the user control - the more flexibility in the way it looks the more likely it will be used by other devs :) Before getting into the detail, lets look at the solution working in the test harness for my WPF F# REPL Engine , shown below are four different themes applied dynamically at run-time - no recompilation required to change the theme: Previously in larger WPF apps I've relied upon third-party control vendors like Telerik to provide theming support. Typically they provide good solutions to the problem with multiple themes supported as standard, and when you're already using their third party controls the use of their themes makes sense. But when you're developing a small UI component you don't want to add (& support) such a large footprint just to add themes to your niche control. A theme is a collection of Styles grouped into a ResourceDictionary in WPF. A ...

In this post I'm going to talk about the WPF user control I'm going to use to display the output from the F# Interactive executable, the previous posts ( here & here ) talked about manipulating the standard input & output streams of the executable to provide the following interface: Loading gist .... The control will render any values generated by the Output property on the interface, the property is an Rx stream which generates a new value when ever the F# Interactive executable outputs a line. The control has basic REPL semantics - user enters a line of text, the line is executed and the output is printed to the screen. The F# Interactive window in Visual Studio is the implementation I'll be copying. I had a look around and found 'WPF Terminal' on CodePlex  it looked promising - fulfills the REPL requirements, until I realised it's using a TextBox  for the rendeing. With a TextBox the text can only be one colour and I need the ability to s...