Jérôme Laban

Controlling actual Thread Priority in WinRT and Windows Phone

Tue, 18 Feb 2014 19:58:00 -0600

tl;dr: Setting the WorkItemPriority in ThreadPool.RunAsync actually changes the thread priority the code runs on, not just the position in the pending work queue.

It’s been a while since I’ve blogged, but this entry has been a finding that had long eluded me and this was a good chance to blog again. If you’re still reading, thanks :)

In the Plain Old (or might I say, complete) .NET framework, there was a pretty useful property named Thread.Priority, which gave a lot of control to app developers. This allowed a very control of what would run, where, and how.

Using this API, you could have CPU bound (hence blocking) code that could run at a very low priority, without the need to be yielded somehow, like it’s suggested now with async and Task.Yield().

I was under the impression, since Windows Phone 8.0 and WinRT 8.0 have been introduced, that there was no available way to control the actual thread priority, since either the property does not exist, or even Thread does not exist anymore.

The suggested counterpart, Task, does not provide such a feature, leaving developers no choice but chunking the work, by using clever tricks or work item priority scheduling.

A hidden gem

In WinRT 8.0+ and Windows Phone 8.0, there is one API, ThreadPool.RunAsync, which is very similar to .NET’s own thread pool, but provides an additional parameter, a WorkItemPriority.

Intuitively, and knowing historically how thread pools work, and that they are supposed to work with relatively small units of work, I thought “Ok, yet another API that will prioritize a work queue…”.

I could not be more wrong!

This API not only schedules in the queue using the work item priority, but also executes the work item with the specified thread priority !

To demonstrate the feature, here’s a simple code sample :

private void Profile()
{
   ThreadPool
      .RunAsync(_ => Run(s => textbox1.Text = s), WorkItemPriority.Low);
   ThreadPool
      .RunAsync(_ => Run(s => textbox2.Text = s), WorkItemPriority.Normal);
   ThreadPool
      .RunAsync(_ => Run(s => textbox3.Text = s), WorkItemPriority.High);
}

private void Run(Actiondisplay)
{
	for (int i = 0; i < int.MaxValue; i++)
	{
		i.ToString(); // Slow things down a litthe bit...
				
		if((i % 100000) == 0)
		{
			Dispatcher.BeginInvoke(() => display(i.ToString()));
		}
	}
}

The result is that after a few seconds, the higher the priority, the higher the number displayed on the screen.

Needless to say, this changes quite a bit of things, where it is definitely possible to having background threads that impact a lot less the dispatcher, even if they are 100% loaded. Good for the UI, good for the user.

That’s it for now, happy threading !

Immutable Data and Memoization in C#, Part 2

Mon, 22 Apr 2013 21:10:00 -0600

tl;dr: Memoization can be associated with the ConditionalWeakTable class, which allows the addition of memoized computation results to immutable types. This makes the memoized results live as long as the instances that was used to create it.

In the first part of this article, we discussed a bit the Memoization pattern in C#. In this second part, we will discuss how to alleviate the memory management issue for memoized computation results.

ConditionalWeakDictionary to the rescue

In .NET 4.0 – quite a while ago now – a new class was added, the ConditionalWeakTable, to help in the creation of dynamic languages based on the DLR, where there was a need to be able to attach data to existing type instances, much like a fictional extension property could be. This topic is not covered much, and since it has to do with the GC, it is often misunderstood.

The idea is pretty simple: It is a dictionary that takes an type instance as a key, and a value associated to it. The key is stored as a weak reference, meaning that the data is held as a hard-reference as long as the key lives. When the key is collected by the GC, the hard-link is removed, making the data available for collection if it’s not referenced anywhere else.

Here’s how to use it:

ConditionalWeakTable<object, object> table 
    = new ConditionalWeakTable<object, object>();

var o1 = new object();
var o2 = new object();
var r2 = new WeakReference(o2);

table.Add(o1, o2);

//Release the reference so it's only kept by the table
o2 = null;

GC.Collect(2);
Console.WriteLine("{0}/{1}", r2.IsAlive, table.GetOrCreateValue(o1));

// Release the key instance, hence releasing o2.
o1 = null;

GC.Collect(2);
Console.WriteLine("{0}", r2.IsAlive);

//
// Output:
//
//      True/System.Object
//      False

Implementing this class without having a privileged access to the GC is pretty tricky. You quickly end up having to perform a weak reference dictionary that you’ll need to cleanup by hand and you’ll need to handle circular references properly. This can end up messy.

Composing the Memoization with the ConditionalWeakTable

Knowing this, it is pretty easy to see that it may be possible to create a version of the AsMemoized() helper that stores its computation results somewhere else, in a memory-friendly fashion.

The result of a computation can be associated with the data that was used to create it, and kept alive as long as the first source lives.

Here’s how this can be implemented :

using Storage = System.Collections.Concurrent.ConcurrentDictionary<object, object>;

public static partial class FuncExtensions
{
    private static ConditionalWeakTable<object, Storage> _weakResults =
        new ConditionalWeakTable<object, Storage>();

    public static Func<TParam, TResult> 
        AsWeakMemoized<TSource, TResult, TParam>(
            this Func<TSource, TParam, TResult> selector,
            TSource source
        )
    {
        return param =>
        {
            // Get the dictionary that associates delegates 
            // to a parameter, on the specified source
            var values = _weakResults.GetOrCreateValue(source);

            object res;

            var key = new { selector, param };

            // Get the result for the combination source/selector/param
            bool cached = values.TryGetValue(key, out res);

            if (!cached)
            {
                res = selector(source, param);

                values[key] = res;
            }

            return (TResult)res;
        };
    }
        
    // Since is not possible to implicitly make a Func<T,U> out
    // of a method group, let's use the source as a function type inference.
    public static TResult ApplyMemoized<TSource, TResult, TParam>(
        this TSource source, Func<TSource, TParam, TResult> selector,
        TParam param
    )
    {
        return selector.AsWeakMemoized(source)(param);
    }
}

And is used like this :

class Program
{
    static void Main(string[] args)
    {
        var data = new Data(42);
        var wr = new WeakReference(data.DoStuff(42));
        var wr2 = new WeakReference(data.DoStuff(42));

        GC.Collect(2);
        Console.WriteLine(wr.IsAlive);

        data = null;

        GC.Collect(2);
        Console.WriteLine(wr.IsAlive);
    }
}

// An immutable type
public class Data
{
    public Data(int value) { Value = value; }
    ~Data() { Console.WriteLine("~Data({0})", Value); }

    public int Value { get; private set; }
}

public static class DataExtensions
{
    public static Data DoStuff(this Data data, int someValue)
    {
        return data.ApplyMemoized(InternalDoStuff, someValue);
    }

    private static Data InternalDoStuff(Data data, int someValue)
    {
        Console.WriteLine("Computing {0}", someValue);
        return new Data(data.Value + someValue);
    }
}

//
// Output: 
//      Computing 42
//      True
//      False
//      ~Data(84)
//      ~Data(42)
//

The ConditionalWeakDictionary takes the instance to attach the result to, a function to memoize, and will return a new delegate that will cache the results for a combination of the source and a parameter.

Note that to reduce the verbosity of the code, since it's not possible to use a method group as a delegate, the ApplyMemoized method is used to take advantage of the few places where the delegate type inference is available.

AsWeakMemoized, the caveats

This helper is far from perfect, and it has to do with the implementation of the ConditionalWeakTable implementation.

Referential Transparency

The documentation says "Two keys are equal if passing them to the Object.ReferenceEquals method returns true.". This means that the even though two instances of the same data may be equal in their value, through IEquatable or GetHashCode/Equals, they will be considered as different. This means that through this helper, type instances are not referentially transparent.

When using AsWeakMemoized, this is an implementation detail that needs to be taken into account. The same computation may be performed twice because the computation will be memoized on a projection of an immutable instance.

I mentioned earlier that implementing a ConditionalWeakTable can be tricky, but implementing referential transparency could be a reason to do it. This would allow for the memoizer to compare values instead of references.

But it would also make memory management a bit more complex, regarding the owner of the computation result. For instance, there is the question of how long a referentially transparent result for a single value should be kept alive, even if the original reference that was used to create the resulting value has been collected.

You might want to go down that road :)

Static delegates

You'll notice that the memoization is using the delegate as a key for the storage. This means that if the provided delegate changes, either because it is a lambda that creates a closure, or because the delegate is created from an instance method, the memoization will not happen.

At the very worse, the memoization will do nothing, or maybe simply allocate a few more bytes every time for the storage of the result.

Occasional Duplicate Work

Finally, you'll notice that there are no locks in this implementation. This means that the computation for a set of inputs may occasionally be executed multiple times in case of a race condition. While this can be a performance issue on systems that do not have enough CPUs (< 4), on greater multicore CPUs, it is acceptable to have the CPUs occasionally compute the same data even if it is discarded, just for the sake of avoiding acquiring locks.

Final words

I personally think that Functional Programming concepts such as Immutability and method purity, along with techniques such as Memoization, are part of the answer to harness the power of multi-core CPUs. CPU Scaling out is not going away, so we'd better make good use of this hardware, using the appropriate development tools.

Immutable Data and Memoization in C#, Part 1

Thu, 18 Apr 2013 20:49:00 -0600

TL;DR: Immutable data and memoization are functional programming concepts that can be applied to C# programming. These patterns have their strengths and weaknesses, discussed a bit in this article.

I’ve grown to not being a great fan a data mutability.

Data mutability can introduce a lot of side effects in the code, and it can be pretty complex to go back in time to know what a specific state was before the code failed. This gets worse when multiple threads are involved, and that tends to happen a lot more these days, now that even phones have multiple cores.

Sure, we can use IntelliTrace to ease that kind of debugging, but that’s pretty much limited to issues you already know about. That means you’re reacting to issues that already happened, you’re not proactively preventing those issues from happening.

So, to address this more reliably, there’s the concept of immutability. When a set of data is built, it cannot change anymore. This means that you can pass it around, do computation with it, use it any place you want, there’s not going to be any subtle concurrency issues because the data changed under your feet.

Immutability and Performance

The thing is, taken as is, immutability is not great friend of performance at first. When a computation is performed, the result is just passed to the next function that needs it, but if there is another function that depends on that same function's output, for the same input, then the computation is performed again.

There’s already a solution for this problem, known as Memoization.

The basic idea is that, if the input data is immutable, and that the computation has no side effect, then for a given set of inputs, the output will always be the same. This in turn, means that the result can be cached for later reuse. This is called Referential Transparency.

Here’s a simple example of memoization :

public static Func<TArg, TResult> 
   AsMemoized<TArg, TResult>(this Func<TArg, TResult> func)
{
    var values = new Dictionary<TArg, TResult>();

    return (v) =>
    {
        TResult value;

        if (!values.TryGetValue(v, out value))
        {
            value = values[v] = func(v);
        }

        return value;
    };
}

And here a simple use for this, where you know the data won’t change :

static void Main(string[] args)
{
    // Get the JIT out of the way
    GetAssignableTypes(typeof(IDisposable));

    Func<Type, Type[]> getAssignableTypes = GetAssignableTypes;
    getAssignableTypes = getAssignableTypes.AsMemoized();

    for (int i = 0; i < 10; i++)
    {
        var sw1 = Stopwatch.StartNew();
        var r1 = getAssignableTypes(typeof(IDisposable)).Length;
        Console.WriteLine(sw1.Elapsed);
    }
}

public static Type[] GetAssignableTypes(Type source)
{
    var r =
        from asm in AppDomain.CurrentDomain.GetAssemblies()
        from type in asm.GetTypes()
        where type.IsAssignableFrom(source)
        select type;

    return r.ToArray();
}

The first call takes about 90ms on my machine, at the rest about 0.7µs to execute.

As most of the time, this is tradeoff between memory and CPU. In this case, the result of the computation is store in a dictionary that is capture in the closure created in the AsMemoized method.

So, as long as the delegate produced by AsMemoized lives, so will the cached data.

Memoization storage and Immutability

But there are multiple issues with this pattern of memoization, meaning that the memoized delegate needs to be stored somewhere.

The first issue is that the memoized delegate can be stored along with an instance that has a greater lifetime. This can work if the overall memoized dataset is not too important, because with a naïve implementation as the one above, the data will not be discarded as long as the outer instance lives. The memoization can be reset, by re-creating the delegate, but it is very coarse.

The second one is about placing the memoized delegate along with the data that was used to create it. The memoized content will live as long as the data is alive, but there is a clear separation of concerns issue. Every time there is a new operation that needs to be performed on this data, then a new delegate has to be created to take care of this.

And finally, if there is a need for composite computation, which takes two or more instances, at this point, storing the delegate can be a memory-management challenge.

Next time

Next time, we'll see how memoization can be a little more friendly with the memory.

Cancellation with Async F#, C# and the Reactive Extensions

Tue, 16 Apr 2013 20:25:00 -0600

TL;DR: C# 5.0 async/await does not include the implicit support for cancellation, and needs to pass CancellationToken instances to every async method. F# and the Reactive Extensions offer solutions to this problem, with both implicit and explicit support for cancellation.

My development style has slowly shifted to a more functional approach, during the past year. I’ve been peeking a F# for a while and that shift to a more functional mindset in C# lends me toward understanding a lot better the concepts behind core features of F#, and more specifically the async “support” in F#.

It’s known that F# inspired a lot the implementation of C# async, but having looked at the way it’s been implemented in F# gives me some more points against the “unfinished” implementation in C#.

Recently, now that people are effectively using async, in real-world scenarios, problems are starting to bubble up, and some to giggle. Async void, async void lambdas, the fact that continuations run mostly on the UI thread when not taken care of properly, obscure exception handling scenarios, the “magic” relation to the SynchronizationContext, that it does not address parallelism, and one that’s been pretty low-key, cancellation.

Cancellation is pretty important, particularly, when the operations can take a pretty long time. If the user awaits an async result, he may have the right to cancel the operation, either because it took too long, or because the rest of the processing is not needed, as the user has gone away. This avoids wasting precious CPU cycles, and sometimes network or I/O related resources for computations for which the result will not be used.

Cancelling a C# async method

Now, consider the following code sample, that tries to cancel the execution of an async method:

public static void Run()
{
    var cts = new CancellationTokenSource();
    Task.Run(async () => await Test(), cts.Token);
    Console.ReadLine();
    cts.Cancel();
    Console.WriteLine("Cancel...");
    Console.ReadLine();
}

private static async Task Test()
{
    while (true)
    {
        await Task.Delay(1000);
        Console.WriteLine("Test...");
    }
}

Which produces the following output :

Test...
Test...
Test...

Cancel...
Test...
Test...
Test...
Test...

The problem here is pretty simple: the cancellation token only cancels the task created by Task.Run(). This can be problematic, particularly if the sub-tasks are computationally intensive, or are making external calls (e.g. an http web request) that effectively need to be cancelled.

With the TPL, the notion of cancellation is present through the concept of CancellationToken. A cancellation token is basically a glorified thread-safe boolean value that tells that it’s creator, a CancellationTokenSource, has been cancelled.

So, there are two things to do to support cancellation in an async method.

First, by passing a CancellationToken explicitly and poll the token frequently :

public static void Run()
{
    var cts = new CancellationTokenSource();
    Task.Run(async () => await Test(cts.Token), cts.Token);
    Console.ReadLine();
    cts.Cancel();
    Console.WriteLine("Cancel...");
    Console.ReadLine();
}

private static async Task Test(CancellationToken token)
{
    while (true)
    {
        await Task.Delay(1000);
        Console.WriteLine("Test...");

        if (token.IsCancellationRequested)
        {
            break;
        }
    }
    Console.WriteLine("Test cancelled");
}

Second, via a delegate passed through CancellationToken.Register:

public static void Run()
{
    var cts = new CancellationTokenSource();
    Task.Run(async () => await Test(cts.Token), cts.Token);
    Console.ReadLine();
    cts.Cancel();
    Console.WriteLine("Cancel...");
    Console.ReadLine();
}

private static async Task Test(CancellationToken token)
{
    var wr = HttpWebRequest.Create("http://1.2.3.4");

    token.Register(() => { 
        Console.WriteLine("Query cancelled");
        wr.Abort(); 
    });

    var r = await Task<WebResponse>.Factory.FromAsync(wr.BeginGetResponse, wr.EndGetResponse, null);

    if (token.IsCancellationRequested)
    {
        return;
    }

    Console.WriteLine("Got a result");
}

There are multiple problems with this approach, one being that the cancellation token parameter needs to appear explicitly in every single method of the call tree. If you have multiple layers of code and abstractions, cancellation becomes pretty much prominent.

Second is, to be thorough, to check the cancellation token as often as possible to avoid continuing doing work if it’s not necessary, even if you've detected that the task has been cancelled.

Cancelling an F# async function

With F#, async is actually a “side-effect” of the more powerful feature called the Computation Expressions. Naively, I see this a super-feature that allows the creation of some of the syntactic sugar based-features of C#, async and the iterators.

Async support takes the form of an Async type, that allows the creation of an “async” computation expression that, in turn, allows for the manipulation of Async<T> returning expressions. If this sounds familiar, you’re spot-on, this is roughly the same as Task<T> and C# async/await.

Now, the interesting thing about these Async<T> expressions is that when created, Async<T> functions respect the cancellation token used when starting the async expression :

open System
open System.Threading
let main argv = 

    let myAsync = 
        async {
            while true do 
                do! Async.Sleep(1000)
                Console.WriteLine(DateTime.Now)
        }

    let tokenSource1 = new System.Threading.CancellationTokenSource()
    let val1 = Async.Start(myAsync, cancellationToken=tokenSource1.Token)    
    Console.ReadLine() |> ignore
    tokenSource1.Cancel()
    Console.ReadLine() |> ignore
    0

When cancelled, the async expression stops processing its content, without any explicit support of the token.

But the most interesting part in this is that this token flows through to the other async expressions !

To better demonstrate this, there is the ability to register a function that will be called when the async expression is called :

let main argv = 

    let r2 = 
        async {
            use! c = Async.OnCancel(fun () -> Console.WriteLine("Cancelled 1"))

            // In case there is a non async computation that needs 
            // to check on cancellation
            let! token = Async.CancellationToken
            
            while true do 
                do! Async.Sleep(1000)
                Console.WriteLine(DateTime.Now)

            return 42
        }

    let r = 
        async {
            use! c = Async.OnCancel(fun () -> Console.WriteLine("Cancelled 2"))

            let! test = r2

            while true do 
                do! Async.Sleep(100)

            return 42
        }

    let tokenSource1 = new System.Threading.CancellationTokenSource()
    let res3 = Async.StartAsTask(r, cancellationToken=tokenSource1.Token)    
    Console.ReadLine() |> ignore
    tokenSource1.Cancel()
    Console.ReadLine() |> ignore
    0

This way, there is no explicit need for passing around a cancellation token, and if it is needed, then it can be used explicitly. There is also the ability to asynchronously get the ambient CancellationToken (which is also async !), in case there is a CPU bound computation that needs to be cancelled. Or you can just call any ! (bang) operator that will automatically check on the cancellation.

Pretty powerful !

Cancelling an Rx query

On the same topic of cancellation, the Reactive Extensions also have the notion of cancellation embedded into the flow.

public static void Run()
{
    var s = Observable.Create(o =>
        {
            var wr = HttpWebRequest.Create("http://1.2.3.4");

            var subscriptions = new CompositeDisposable();

            subscriptions.Add(Disposable.Create(() => wr.Abort()));

            var s = Observable
                .FromAsyncPattern(wr.BeginGetResponse, wr.EndGetResponse)()
                .Subscribe(o);

            subscriptions.Add(s);

            return subscriptions;
        }
    )
    .Subscribe(_ => Console.WriteLine("Got result"));

    Console.ReadLine();
    s.Dispose();
    Console.ReadLine();
}

Every observable can be subscribed to, and returns a disposable instance. Whenever the final subscription gets disposed, the whole query gets disposed as well, along with the ability to intercept that disposition with the Observable.Create operator.

Final words…

Cancellation is an important topic that has been “forgotten” in C# async. This is a very important topic, and this one adds up to all the others about the implementation in C# 5.0, for which I hope this will get fixed in a future release in the language.

For the moment, both Rx and F# approach async in a more thorough manner, and moreover, attack head-on the concurrency side of asynchrony which is ignored by C# 5.0...

If you're interested in a more detailed comparison of F# and C# on the subject, read Tomas Petricek blog post series.

Building in Parallel Across Multiple Build Agents in TFS2012 for Metro Apps

Sat, 30 Mar 2013 12:50:00 -0600

TL;DR: Using an upgraded (and fixed) Parallel Build Process Template allows to use multiple TFS2012 build agents simultaneously, which can be more than welcome when building metro apps that target all three supported platforms. A build that took 11 minutes can go down to 3.5 minutes.

Download the Parallel Build Process Template for TFS2012 here.

CI is a wonderful feature, especially when associated with Gated Checkins.

You’re certain that what’s in your source control is in line with your build definition and constraints, and that there is always a binary that respects a minimum set of rules. This does not ensure that your app is bug free, but still, that’s a minimum.

Build time matters

The downside of this validation is that there cannot be multiple builds running at the same time. This can become a bottleneck when multiple developers checkin within the duration of a single build run.

This means that the longer your build gets, the longer a developer might wait for its task completion because of a long build queue, and increase its task switching cost. If a build fails, the developer needs to unshelve its changes, make the necessary adjustments, then check-in again.

Below 4 minutes of build time, this stays in the acceptable range where the developer’s task context may not be lost if the build fails.

The case of Metro Apps

Metro apps are a bit tricky in this regard, because when a .NET based app needs a native dependency, such as Bing Maps SDK, then it is not possible to use the Any CPU configuration anymore.

In such case, building the app requires the target the three Metro Apps supported platforms: ARM, x86, x64.

The msbuild configuration for metro apps enforces that all projects for a single platform be compiled under the same platform, meaning that every assembly must be build three times to produce a complete app submission package.

If your build takes 4 minutes for one platform, then multiply it by three (or more) for all platforms. This is where the CI build time gets in the way of development efficiency.

And if you’re multi-targeting to include Windows Phone apps, and desktop apps that share code with metro apps, Build Time can get out of hand very quickly. And I'm not even mentioning obfuscation...

Building in Parallel

I’m a fan of msbuild projects authoring (over Workflow authoring) but in this case, msbuild does not cut it. This will probably please my TFS MVP friend Etienne Margraff, which gives a lot of love to customizing its workflows.

When building using msbuild, parallelization can occur inside a single solution, for a single Configuration/Platform combination. While this improve the build time a bit, this does not work at all for multiple combinations.

There’s also the trick that the guys over a the MSBuild Extension Pack that enables the execution of multiple tasks inside of a single MSBuild project file to run in parallel. The problem with this is that the same source tree is used for all builds at the same time, which can cause trouble over shared files or resources. You have to make sure that all projects include the platform in their respective outputs, but even with that, you can’t be sure that a race condition might not happen at any time.

Using the Parallel Build Process Template

A few years back, a Jim Lamb posted a custom Build Process Template that allows to build multiple configurations in parallel. The beauty of this template is that it allows for each configuration to run on a separate build agent !

This means that the build can be split on multiple machines, running each on their own copy of the source tree, avoiding race conditions over shared resources from the source tree.

I’ve migrated a few projects over to this updated template and the results are very interesting. A build that would take 11 minutes to run would fall down to 3.5 minutes when ran over three build agents on the same machine.

One thing though, the original template is built for TFS2010, so I had to port it over to TFS2012 using this cleanup tool from Jason Prickett. If you don’t want to migrate it by yourself, download the file at the top of the post.

I also had to modify the original error handling, because if one of the configuration build failed, the overall build would not fail. In the context of a gated checkin, this can be problematic…

Getting a bit farther

The interesting thing with this parallel build template is that it can be used to parallelize validation or non-output generating tasks. For instance, creating a zip file of the source tree, validating some portions of the xaml for best practices, running some non-interactive unit tests… and so on.

This relies on scaling out, instead of scaling up, which is more than welcome, particularly in virtualized environments.

[VS2012] Temporarily disable the C# static code analysis for a whole VS instance

Sat, 30 Mar 2013 11:52:00 -0600

TL;DR: It is possible to disable the Static Analysis phase in VS2012 projects by setting the DevDivCodeAnalysisRunType environment variable to “Disabled”.

This will be a quick post, but which might save you a lot of time if you rely heavily on Code Analysis (FxCop).

FxCop is definitely not known for its analysis speed, and when ran in every build, this takes a lot of time. I usually work on projects where FxCop is only enabled in the Release Configuration, which helps during development in Debug configuration.

But if you’re bound to run in Release configuration, such as when profiling the app, or any other task that requires to build in that configuration, then having FxCop running every single time can be time consuming.

To avoid this, there are multiple choices :

Use find and replace to change <RunCodeAnalysis>true</RunCodeAnalysis> to <RunCodeAnalysis>false</RunCodeAnalysis>, but then you have to remember to not check that into your source control (even if the Perform Code Analysis setting is set to Always in your CI Build definition),
Create an alternate configuration similar to Release that does not have the Static Code Analysis enabled, but changing configurations in VS2012 can take time (even with the Update 2) and you’ll have to maintain that configuration with the others,
Or you can use a little trick to disable the static code analysis for a whole Visual Studio instance.

That trick is a bit hidden, but here’s how you can do this :

Open a Developer Command Prompt for VS2012
type set DevDivCodeAnalysisRunType=Disabled
type devenv

Build your solution and you won’t have the static analysis running, without any modification to your solutions’ configuration or projects. Easy.

That said, remember that this is not documented and might change at any point in the future so don't rely on it too much.

Writing a Xaml attached property in C++/CX to resize Images, with a Performance twist

Mon, 04 Feb 2013 21:41:00 -0600

TL;DR: Writing Xaml/C++ attached properties sometimes gives a 30% improvement over the C# version, which can be caused by the use of events. This article shows code sample for both versions.

Since it is possible to write a XAML application entirely in C++/CX, I decided to give a try to the performance of some simple code.

There is, after all, some marshaling involved when communicating from C# to native code, particularly with events.

The ImageDecodeSizeBehavior

WinRT’s BitmapImage class supports, as does WPF and Silverlight, the DecodePixelWidth and DecodePixelHeight properties.

These are very useful properties that forces the memory surface to store the image to fit a certain size, and avoid the waste of memory induced by large downscaled images. This is a very common performance issue for applications that display variable sized images, where the memory can grow very quickly.

So in C#, the following attached property can be written pretty easily :

public static class ImageDecodeSizeBehavior
{
    public static void SetSource(Image image, string value)
    {
        image.SetValue(SourceProperty, value);
    }

    public static string GetSource(Image image)
    {
        return (string)image.GetValue(SourceProperty);
    }

    public static readonly DependencyProperty SourceProperty =
        DependencyProperty.Register(
            "Source",
            typeof(string), 
            typeof(ImageDecodeSizeBehavior), 
            new PropertyMetadata(null, (s, e) => OnSourceChanged(s, e))
        );

    private static void OnSourceChanged(DependencyObject s, DependencyPropertyChangedEventArgs e)
    {
        var image = (Image)s;

	    image.SetValue(SourceProperty, e.NewValue);

	    image.SizeChanged += (_, __) => RefreshBitmap(image);

	    RefreshBitmap(image);
    }

    private static void RefreshBitmap(Image image)
    {
	    var source = (String)image.GetValue(SourceProperty);

	    if(source != null)
	    {
		    var uri = new Uri(source);
		    var bitmap = new BitmapImage(uri);

		    bitmap.DecodePixelWidth = (int)image.Width;
		    bitmap.DecodePixelHeight = (int)image.Height;

		    image.Source = bitmap;
	    }
    }
}

The idea here is to use the current image control size as the target surface size, do be gentle with the memory. The downside is that if images need to be zoomed in, then they're going to be pixelated, unless the image is re-created.

In this sample, the hook on SizeChanged is more of a speed test, because one would not want to re-create the image every time the size changes, particularly if it changes too much (though the Rx Throttle operator may help).

It’s used that way :

<Image local:ImageDecodeSizeBehavior.Source="{Binding}" Width="50" Height="50" />

The same, in C++/CX

With C++/CX, the code is looking very much like its C# counter part :

using namespace Platform;
using namespace Windows::UI::Xaml;
using namespace Windows::UI::Xaml::Controls;
using namespace Windows::UI::Xaml::Interop;
using namespace Windows::UI::Xaml::Media::Imaging;
using namespace Windows::Foundation;
using namespace Windows::Foundation::Metadata;

public ref class ImageDecodeSizeBehavior sealed : DependencyObject
{
public:
	ImageDecodeSizeBehavior();

	static property DependencyProperty^ SourceProperty { 
		DependencyProperty^ get() { return _sourceProperty; }
	}

	static String^ ImageDecodeSizeBehavior::GetSource(Image^ image) {
		return (String^)image->GetValue(SourceProperty);
	}

	static void ImageDecodeSizeBehavior::SetSource(Image^ image, String^ source) {
		image->SetValue(SourceProperty, source);
	}

private:
	~ImageDecodeSizeBehavior();

	static DependencyProperty^ _sourceProperty;

	static void RefreshBitmap(Image^ image, String^ value);
	static void OnSourceChanged(DependencyObject^ d, DependencyPropertyChangedEventArgs^ e);
};

And the cpp file:

using namespace Platform;
using namespace Windows::Foundation;
using namespace Windows::Foundation::Collections;
using namespace Windows::UI::Xaml;
using namespace Windows::UI::Xaml::Controls;
using namespace Windows::UI::Xaml::Data;
using namespace Windows::UI::Xaml::Documents;
using namespace Windows::UI::Xaml::Input;
using namespace Windows::UI::Xaml::Interop;
using namespace Windows::UI::Xaml::Media;
using namespace Windows::UI::Xaml::Media::Imaging;

DependencyProperty^ ImageDecodeSizeBehavior::_sourceProperty = 
	DependencyProperty::RegisterAttached(
		"Source", 
		TypeName(String::typeid), 
		TypeName(ImageDecodeSizeBehavior::typeid), 
		ref new PropertyMetadata(
			nullptr, 
			ref new PropertyChangedCallback(OnSourceChanged)
		)
	);

void ImageDecodeSizeBehavior::OnSourceChanged(DependencyObject^ d, DependencyPropertyChangedEventArgs^ e)
{
	auto image = (Image^)d;
	auto value = (String^)e->NewValue;

	image->SetValue(SourceProperty, value);

	auto sizeChanged = [=](Object^ sender, SizeChangedEventArgs^){
			RefreshBitmap(image, value);
	};

	image->SizeChanged += ref new SizeChangedEventHandler(sizeChanged);

	RefreshBitmap(image, value);
}


void ImageDecodeSizeBehavior::RefreshBitmap(Image^ image, String^ source)
{
	if(source == nullptr)
	{
		source = (String^)image->GetValue(SourceProperty);
	}

	if(source != nullptr)
	{
		auto uri = ref new Uri(source);
		auto bitmap = ref new BitmapImage(uri);

		bitmap->DecodePixelWidth = (int)image->Width;
		bitmap->DecodePixelHeight = (int)image->Height;

		image->Source = bitmap;
	}
}

Except that it’s a lot more verbose. Particularly the lambda syntax that uses all the available braces on the keyboard.

Performance

How do the two compare, in terms of performance ? Testing this in a real control is a bit complex, because of the performance issue I outlined in this post, but also because the measured time varies a lot, of about +/- 2%. This margin of error is not small enough to show the actual improvements.

Still, it is possible to measure in a more isolated code :

var w = Stopwatch.StartNew();
for (int i = 0; i < 1000; i++)
{
   var b = new Image();
   ImageDecodeSizeBehavior.SetSource(b, "http://google.com/images/srpr/logo3w.png");
}
var elapsed = w.Elapsed;

Which shows that, on a Surface RT, attaching to 1000 images takes 722ms in C#, and 505ms in C++/CX, which is about a 30% faster.

Now, the reason for this difference is the event registration.

Removing both event registrations sets the bar to 474ms for C++/CX and 493ms for C#, which almost accounts for all the complexity added by the hidden EventRegistrationToken and WindowsRuntimeMarshal.AddEventHandler magic added by the C# compiler.

The simple += operator added in C# is expanded to something like this, in IL :

WindowsRuntimeMarshal.AddEventHandler(
   new Func(image.add_SizeChanged), 
   new Action(image.remove_SizeChanged), 
   delegate(object _, SizeChangedEventArgs __) {
      ImageDecodeSizeBehavior.RefreshBitmap(image);
   }
);

Which is a bit of a change from a simple delegate registration. I'm guessing that there is a lot of work related to reference tracking and marshalling, under the hood, which may account for the loss of performance.

It is worth the investment ?

We’re talking about quite small amounts of time, yet we’ve got 16.6ms to perform operations on the UI thread, and keep the 60fps rate to preserve smooth animations. So, 0.7ms may count in the balance.

C++/CX requires a bit more maintenance than its C# counterpart, which may add to the development cost. It also forces the creation of packages for all the available platforms, as it requires the creation of a native WinMD component.

I, for one, tend to favor maintainability over performance, unless it is in a very critical path.

On the Performance of WinRT/Xaml Template Expansion

Sat, 02 Feb 2013 15:11:00 -0600

TL;DR: Expanding data-bound item templates in Xaml/WinRT in Windows 8 is about a hundred times slower than with Xaml/WPF. This article details how this was measured and a possible explanation.

In Windows 8, Microsoft has a introduced a whole new Xaml stack, codenamed Jupiter, completely re-written to be native only.

This allows the creation of Xaml controls using C++ as well as C#.

I will not discuss the philosophical choice of ditching managed WPF in favor of a native rewrite, but make a simple comparison of the performance between the two.

Template Expansion Performance

I worked on a project that had performance issues for a UI-Virtualized control, where the initial binding of data as well as the realization of item templates, was having a significant impact on the fluidity of the scrolling of a GridView control.

To isolate this, I created a simple UI:

<GridView x:Name="testGrid">
    <GridView.ItemsPanel>
        <ItemsPanelTemplate>
            <VariableSizedWrapGrid />
        </ItemsPanelTemplate>
    </GridView.ItemsPanel>
    <GridView.ItemTemplate>
        <DataTemplate>
            <TextBlock Text="{Binding}" Foreground="Red" />
        </DataTemplate>
    </GridView.ItemTemplate>
</GridView>

Initialized with the following code in a button click :

testGrid.ItemsSource = Enumerable.Range(1, 100);

On a Surface RT tablet, the time during which the UI was not responding was about 2.1 seconds.

Looking a the profiler revealed that a lot of time was spent in this function :

?MeasureOverride@FrameworkElementGenerated@DirectUI@@UAAJUSize@Foundation@Windows@@PAU345@@Z

Measuring is expected to take some time to execute, but it was very odd that it was that much.

Measuring between WPF and WinRT

As an experiment, I tried to create approximately same layout in WPF, and test the rendering performance on my PC.

To measure more precisely, I created an override of both the GridView and the ListBox controls so that the call to Measure could be profiled, that way :

protected override Size MeasureOverride(Size availableSize)
{
   var w = Stopwatch.StartNew();
   try 
   {             
      return base.MeasureOverride(availableSize); 
   }
   finally        
   {                 
      MeasureTime = w.Elapsed;    
      Debug.WriteLine("Measure " + w.Elapsed);         
   }       
}

It turns out that the initial measure duration for 500 element is quite different: WPF measures for 15ms, WinRT does in 1500ms ! And it appears visually, because the UI is not responding a long time in WinRT, where it does not in WPF. Subsequent measures are roughly the same for both platforms.

Interestingly, while the VS2012 profiler does not show stack traces below the manaded/native boundary, the concurrency visualizer does. A stacktrace element that comes back very often is the following :

windows.ui.xaml.dll!XamlWriter::WriteNode+0x53c

Which seems to point in the direction of the lack of template parsing result caching…

What then ?

That’s the problem. Not that much, apart from try to not realize too many collection items in WinRT. (and guessing that for the next update of WinRT that may address this)

Another solution can be to Databind an ObservableCollection and add items slowly to yield the template creation on the UI Thread... But this requires some plumbing code to avoid race conditions and sorting issues.

This makes UI virtualization very important with Virtualizing Panels, to reuse as many control instances as possible. This also implies that your visual design should not display too many items at once on the screen, with small logical dimensions.

An RxJS to Rx.NET bridge

Tue, 22 Jan 2013 21:19:00 -0600

tl;dr: JavaScript can call C# code in Metro apps, and allows for C# code to observe notifications coming from JavaScript, using the Reactive Extensions grammar.

Javascript is (almost) everywhere, literally.

Not in everyone's minds though, which is only around 7% according to the PYPL index.

Yet, Microsoft is pushing a lot on that front, particularly in Metro apps where the documentation shows JavaScript examples first. Subjectively, I’m not a big fan of the decision, because it pushes us back a few years and not simply because of the language, but because state of the full JavaScript ecosystem, compared to the .NET counterpart.

JavaScript ?

Quirkiness of the language aside, things are going in a good direction -- particularly for large applications -- with TypeScript, where type safety is introduced, among other things.

Arguably, JavaScript is not very good a parallelism (which is very different from asynchrony), mainly because it is single-threaded. There are ways around it, like using Web Workers, but this is bare-metal isolated parallelism, where everything needs to be done by hand. Maybe soon enough, we’ll end up with someone reinventing a .NET Remoting (or DCOM) look alike to address these issues.

We’re going in a multi-core CPU direction, because processors scaling up seems to have slowed down quite a bit, and that scaling out is now the trend. The immutability trend seems to rise here and there to embrace this change, C# hints at taking that route with BCL’s immutable collections, and F# has it at its core.

I foresee JavaScript lagging behind in that regard, but maybe that’s not a problem for now because it is used as an HTML back-end (and used it for this only for the time being). We still need to address a lot of concerns with raw performance, particularly when applications are not just displaying data, but are actually performing a lot of business computation on the client side.

Mixing C# and JavaScript

Fortunately, there is a very good way to do actual parallelism in Metro apps because of two things :

JavaScript can call WinMD files code
C# can expose code as WinMD files

and in C#, there is Rx.NET that excels at mixing both asynchrony and parallelism. It is very easy to share and use immutable data using Rx and its Query based programming which makes it a good fit.

It’s actually pretty easy to create a mixed environments application :

Create a WinJS app
Create a C# Windows Runtime Component, which creates a WinMD file
Add a reference to the WinMD project in the WinJS project
Call some code, and voila !

Sounds too good to be that easy ? Yeah, you’re actually right…

Bridging RxJS and Rx.NET

Microsoft’s preferred way for exchanging messaging is through events. Even in WinMD type definitions, and pretty much all APIs in WinRT expose some sort of .NET like events.

I’m not a big fan of events, for subscription lifetime, memory management, composition, delegation, … I’m transforming them into Rx observable where ever I can, and being able to have a common way for exchanging asynchronous notifications, using multi-valued returning functions, between both worlds seems a pretty good way to go.

Both RxJS and Rx.NET seem to share the same notification grammar, meaning that it is should be very easy to map between the two.

But there is a problem with all this, being that JavaScript objects, as far as I know, cannot be marshaled through to .NET. Only WinMD exposed types, primitives and delegates can. If you try to pass a Javascript object, you’ll be greeted with a Type Mismatch exception…

Exposing an RxJS observable to Rx.NET

The idea is to be able to expose an RxJS observable to an Rx.NET C# observer, and subscribe to it.

Note: Excuse my JavaScript, I’m probably using it somehow the wrong way… Feel free to correct me !

First, here is the JavaScript observable we want to subscribe to :

var observable = Rx.Observable.return(42);

To be able to pass this around we need to expose a way to subscribe to that observable inside JavaScript, but allow for C# to provide onNext, onError and onCompleted handlers, but also a way to dispose the created subscription :

Rx.Observable.prototype.toWrapper = function () {
        var parent = this;
        return new Umbrella.ObservableWrapper(
            function (onNext, onError, onCompleted) {
                var subscription = parent.subscribe(
                   onNext, 
                   function (e) { return onError(e.toString()); },
                   onCompleted
                );

                return function () { subscription.dispose(); }
            }
        );
    };

For the same reasons we can’t pass the observable directly to C#, we can’t pass the subscription returned by to subscribe back to C#. We also can’t pass the exception as-is.

The trick here is to provide a first function that create the subscription, and return another that disposes it.

The ObservableWrapper class is a WinMD exposed C# class that takes this form :

public sealed class ObservableWrapper
    {
        private SubscribeHandler _subscribe;

 
        public ObservableWrapper(SubscribeHandler subscribe)
        {
            _subscribe = subscribe;
        }

 
        internal IObservable<object> AsObservable()
        {
            return Observable.Create<object>(o => {
                var disposeAction = _subscribe(
                    v => o.OnNext(v), 
                    e => o.OnError(new Exception(e.ToString())),
                    o.OnCompleted
                );
 
                return Disposable.Create(() => disposeAction());
            });
        }
    }

The wrapper is created with a delegate that calls subscribe, and the observer is decomposed as three lambdas for the notifications. The subscribe delegate create a delegate that will dispose the subscription on the JavaScript side, when the C# observable will be disposed.

Also note that the class is sealed, and that the AsObservable method is internal, because it exposes .NET only types and will only be used from .NET code.

Next, C# methods can then take ObservableWrapper instances as parameters, which can be subscribed to :

public void DoStuff(ObservableWrapper wrapper)
{
   var s = 
      wrapper
       .AsObservable()
       .Subscribe(
          v => Debug.WriteLine(v), 
          e => Debug.WriteLine(e),
          () => Debug.WriteLine("Completed")
       );
}

It can then used like this, on the JavaScript side :

var foo = new MyApp.Foo(); 
foo.doStuff(observable.toWrapper());

All this works pretty well !

I’ll probably talk on how to do it the other way around in another blog post, as there are some other tricks to use to make this work.

ReaderWriterLockSlim on Windows Phone 8 and the seemingly random MethodAccessException

Sun, 13 Jan 2013 15:02:00 -0600

TL;DR: Don't use the ReaderWriterLockSlim class on Windows Phone 8 RTM, it has a bug that appears only under contention.

Windows Phone 8’s move to the NT kernel has had a lot of advantages for the developer, such as the move to the same .NET CLR as the Desktop Windows, but also the ability to have multi-core based environment.

More specifically, there is one access synchronization – the ReaderWriterLockSlim – which makes a lot of sense in real multi-core environment.

I’ve been using this class to synchronize access to a dictionary abstraction for performance reasons and also for legacy reasons, since that the Concurrent Collections are available. Note that we do have a new tool in the toolbox, the BCL Immutable Collections, that are becoming my new preferred way for creating collections.

The (seemingly) random System.MissingMethodException

After moving a project to Windows Phone 8, I started seeing this MethodAccessException sporadically, seemingly without any reason :

[System.MethodAccessException]
Attempt by method 'System.Threading.ReaderWriterLockSlim.WaitOnEvent(System.Threading.EventWaitHandle, UInt32 ByRef, TimeoutTracker)' to access method 'System.Threading.WaitHandle.WaitOne(Int32, Boolean)' failed.

Which seems a bit odd.

I was able to reproduce the issue this way :

var r = new ReaderWriterLockSlim();
r.TryEnterUpgradeableReadLock(-1); 
r.TryEnterWriteLock(-1);
ThreadPool.QueueUserWorkItem(_ => { r.TryEnterWriteLock(-1); });

With this code pasted in the constructor of the app.xaml.cs file of an empty app.

This means that until there is actual contention on the lock, the bug will not show up. This makes it show up seemingly randomly.

A bit of geeky digging

As always, I just can't let an issue like this not deeply understood, and I've dug a bit deeper to understand why this is happening.

In Windows Phone 8, the ReaderWriterLockSlim type is in the System.Core.dll assembly, and considering the exception stack trace and message, the ReaderWriterLockSlim.WaitOnEvent method is trying to access the WaitHandle.WaitOne(Int32, Boolean) method which is located in the mscorlib.dll assembly.

The problem is actually pretty simple: The WaitHandle.WaitOne(Int32, Boolean) method is declared as private in another assembly, making the runtime fail when linking the method.

This brings another interesting insight on how Microsoft handles the Framework, because this code could not have been compiled using the current set of assemblies. Somehow, the System.Core.dll was built using a different mscorlib.dll which has this method either public or most probably internal (because mscorlib.dll has the InternalsVisibleTo("System.Core") attribute set).

A workaround

To my knowledge, this issue is present in Windows Phone 8 RTM (Apollo), and I’ve not been able to validate that this is still present in the Portico update.

For the time being, I’ve moved back to a Monitor based synchronization mechanism until this gets fixed.

So in short, don’t use ReaderWriterLockSlim on Apollo.

Toying around with F# Queries, Rx, Portables Libraries, Windows [Phone] 8 and the Zip operator

Wed, 02 Jan 2013 22:42:00 -0600

Agreed, that’s a lot of keywords. Yet, they fit one another in a very interesting way.

I find more and more that F#, particularly regarding the way my development trends are going, is getting more and more of a fit regarding the immutability and flexibility needs.

Given that, I thought I’d give a try at running some F# Query Expressions using custom Rx operators, on Windows Phone 8, using Portable Libraries.

Getting F# to run on Windows Phone 8

Interestingly, the F# team made a portable library version of their runtime, so that it can run under the intersection of .NET 4.5, Windows Store Apps and Silverlight 5 frameworks. Windows Phone 8 projects accept this intersection, which make F# available to work with.

That was easy.

Getting Rx to run on F#’s PLib intersection

That one is a bit more tricky. Out of the box, Rx supports a different PLib frameworks intersection, being .NET 4.5 and Windows Store Apps.

Fortunately, the Rx team published the source code of the library, making this experiment a lot easier to do.

I’ve updated a bit the Rx sources to match a set of new defines :

<DefineConstants>
$(DefineConstants);NO_RXINTERFACES;PREFER_ASYNC;
HAS_APTCA;NO_HASHSET;NO_CDS;NO_SEMAPHORE;NO_STOPWATCH;
NO_REMOTING;NO_SERIALIZABLE;NO_THREAD;PLIB
</DefineConstants>

I’ve also changed the PLib profile from Profile7 and Profile47, to match the same profile as the F# portable library. There’s actually a new define I introduced, NO_SEMAPHORE, because that new profile does not support the SemaphoreSlim class.

I had to make a small update to the code to make that code Semaphore-less, if you’re interested let me know, I’ll share that.

Playing with the F# Query Expressions and Rx

I’ve come across an interesting article from Marcin Najder about F# 3.0 and Query Expressions using the Reactive Extensions and this got me started.

The interesting side is to be able to have comprehensions that simplify the writing of queries that contain LINQ or Rx operators that may not be supported by C#, such as IObservable.Take() :

type Dummy() = 
 
        let rxquery = new RxQueryBuiler()
        let obs = new ObsBuiler()
 
        let values =
            obs {
                for value in [0..15] do
                    yield value
            }
           
        member this.Foo = 
            rxquery {
                for value in values do
                where (value > 1)
                select value
                take 10 into trimmed
                select trimmed 
            }

The Foo property can be used directly from a C# program, and observed like any other IObservable instance.

The ZipLike custom operator

With Rx and their enumerable counterparts (such as Linq), the Zip operator allows to get two streams of values and produce another using each tuple of values.

The problem with this operator is that in C# it cannot be written using the “from xx in yy” LINQ syntax, because there is no keyword for it, and the language does not allow the creation of new ones (though some are trying to get that into future C# versions).

There are no examples or documentation anywhere to use a custom Zip operator (using the CustomOperation.IsLikeZip property), so digging a bit into the F# test suite got me started on how to use it.

So, instead of writing a Zip like this :

o1.Zip(o2, (lv, rv) => new Tuple(lv, rv));

It can be written like this in F#, by defining a custom zip operator :

    let values2 =
        obs {
            for value in [5..20] do
                yield value
        }

    member this.Combined = 
        rxquery {
            for test in values do
            zip test2 in values2
            select (test, test2)
        }

This returns a simple tuple for the combined values.

But this also has the advantage of providing what the C# let keyword does, by creating query variables :

        member this.Combined = 
            rxquery {
                for test in values do
                zip test2 in values2
                let values = (test * 2, test2)
                where (fst(values) > 5)
                select (test, test2)
            }

There is no need to create temporary anonymous types to forward the state of the query to downstream Rx operators manually.

Cool stuff, really.

Reading the content of the Xap/Appx and IsoStore in Windows [Phone] 8

Thu, 20 Dec 2012 09:57:00 -0600

In Windows Phone 8, things got better of the front of reading the file system. It’s actually gotten closer to the Windows 8 with the inclusion of WinRT, and it now possible to read the content of files that were pretty hard (or impossible) to access directly before.

Reading the app package content files

There are some times when you need to access the content of the xap directly, and in Windows Phone 7, you were pretty limited to the use of the IsolatedStorage, but really did not have access to the content of the Xap, except for some location such as images or XmlDocument and the SQL CE engine using the appdata:/ scheme.

Things have changed in Windows Phone 8, and here’s how to read the WMAppManifest.xml file by yourself :

   var file = await StorageFile.GetFileFromPathAsync(
      Path.Combine(
         Windows.ApplicationModel.Package.Current.InstalledLocation.Path,   
         "WMAppManifest.xml"
      ) 
   );

   using (var stream = new StreamReader(await file.OpenStreamForReadAsync()))
   {
      var content = await stream.ReadToEndAsync();
   }

That way, you can access anything located in your package, and use it like any other file. Also note that this technique is also working on Windows 8.

Reading the content of the IsolatedStorage

The IsolatedStorage class is just a wrapper around the file system that was introduced in .NET a while back, but since it is now possible to access the file system using WinRT, it is possible to read the isolated storage folder content directly.

It’s just a matter of using Windows.Storage.ApplicationData.Current.LocalFolder and replicating the code above, which will make for a very portable code between Windows 8 and Windows Phone 8.

DataBinding performance in WinRT and the Bindable attribute

Mon, 26 Nov 2012 20:51:00 -0600

tl;dr: The Bindable attribute can be placed on standard C# classes in Metro Apps to make them appear in the generated IXamlMetadataProvider class, to create static metadata. This technique allows for a 10% increase in data-binding performance over reflection based binding, but also adds a temporary cost in JITting, until Windows generates native images 24 hours later.

Databinding in WPF/WinRT is very easy to use. Just put the name of the field you want to bind, set the DataContext, and voila, it is displayed on screen. Yet, this is a tricky feature under the hood. It relies on the presence of an arbitrary string that may exist in the current DataContext to get the data to be displayed.

In WPF and Silverlight, this is fairly easy to do because everything is in managed code. Resolving that data member was performed using a bit of type Reflection, where the string "{Binding SomeValue}" would result in a sequence of Type.GetProperty to get a PropertyInfo instance, then call GetValue to get the actual value.

But in WinRT, all this is a lot different, mainly because WinRT is purely native and there is no reflection or metadata there.

Reflection for C#/XAML apps using WinRT

How does that work then? Well, that’s where some magic happens during the compilation of a C#/XAML project, a subject that I covered a while back.

The compilation process parses the Xaml files to find nodes that reference actual C# or WinMD defined types, and generates a fairly big class that implements the IXamlMetadataProvider class. This class will provide detailed information about the types such as how to create them, their members, whether they are read-only or not, enum values, if there is a content property, etc…

This generated class is basically a static reflection engine for WinRT. At runtime, this class is provided to WinRT which in turn, calls it to determine what to do with the nodes it just parsed.

The magic with DataBinding POCO classes

There’s actually one interesting scenario, when using databinding POCO classes. Let’s say you write this:

<TextBlock x:Name=”test” Text={Binding MyValue}” />

Create the following class:

public class MyClass
{
   public string MyValue { get; set; }
}

And DataBind it using this code :

test.DataContext = new MyClass { MyValue = “Hello world !” };

Everything will work as expected.

But if you look at the generated IXamlMetadataProvider class, you’ll notice that there no reference to the MyClass type.

I stated previously that WinRT can’t do reflection, so how does that work? Simple. .NET Runtime magic !

Digging a bit deeper, by placing a breakpoint behind the C# auto property, we’ll find this stack trace:

--> MyApp.exe!MyApp.MyClass.MyValue.get()
    [Native to Managed Transition]
    mscorlib.dll!System.Runtime.InteropServices.WindowsRuntime.CustomPropertyImpl.InvokeInternal(object target, object[] args, bool getValue)
    mscorlib.dll!System.Runtime.InteropServices.WindowsRuntime.CustomPropertyImpl.GetValue(object target)
    [Native to Managed Transition]
    [Managed to Native Transition]
    MyApp.exe!MyApp.MainPage.Test()

The runtime provides a way for WinRT to actually be able to perform reflection on arbitrary types that are not known at compile time by the IXamlMetadataProvider implementation, using the internal CustomPropertyImpl class.

This is completely transparent to the developer, and works very efficiently.

Adding a POCO to the IXamlMetadataProvider

Knowing that DataBinding also works in a completely native environment using C++/CX, tells some very interesting information.

To be able to databind a type in a C++/XAML app, it is required to place the Bindable attribute. This will force the C++ compiler to generate code that performs the same static reflection class found in C#/Xaml apps. A similar IXamlMetadataProvider implementing class will be generated with this metadata, allowing the Xaml parser to work properly, the same way it does with C#.

When looking at the documentation for Bindable, here what can be read:

“Specifies that a type defined in C++ can be used for binding.”

Which implies that it should only be used for C++ created types.

Yet, because this attribute is defined in WinRT, it can be used on C# classes, and surprise, classes marked with it also get added to the generated IXamlMetadataProvider !

This attribute can also be used to mark types as Bindable when provided in another assembly, but that are never referenced in Xaml.

I’m a big fan of code generation over reflection, particularly if what’s being reflected upon is known at compile time. I firmly believe that it is most of the time a way better use of CPU power to perform this code generation a compile time, over doing it countless times on the client at runtime.

This is why I’ll favor generating code, and this "Bindable" finding sound like music to my ears…

Profiling the Binding performance using Reflected and Bindable marked types

But let’s be clear. Microsoft did not think this technique would be interesting, because they would have otherwise told to add that attribute to classes. Still, let’s see how both binding infrastructure perform.

Before that, there are actually two things to consider.

First, the generated code for the IXamlMetadataProvider is not free. Even if it is mostly non-conditional, it still needs to be executed when the app starts to build the type definitions to provide to the WinRT Xaml engine. If this class grows very big, this may adversely impact the performance of the metadata lookup. A big switch/case on strings construct is translated into a standard IDictionary<string, int>, and reading this dictionary is not free.

Second, if there are lots of bindable types, even if the provider is composed of a single big switch/case and lots of small get/set methods, this means that this big method will need to be JITed. This can take a substantial amount of time at the startup of the app. This begs for NGEN though, as I’ve discussed in a previous article, to eliminate this overhead.

Testing the startup speed

Testing the startup speed can be done using code generation using T4. Considering an app that has around 30 databind-able types, all comprised of 15 fields, here’s the startup time up to the data observed on the screen of a Surface RT:

Reflection, 1.9s with JIT, 1.8s with NGEN
Bindable, 3.1s with JIT, 1.8s with NGEN

Testing the binding speed

Testing the binding speed be done using two simple types (one with the Bindable attribute, the other without), with one field, both databound to a TextBlock Text property. The loop is about setting 5000 times the DataContext to a new instance of the type:

Reflection: 2.00s with a string, 2.45s with an int
Bindable: 1.78s with a string, 2.20s with an int

This makes for improvement of about 10%, which is interesting, particularly considering the fact that ARM tablets are not that powerful.

Unsurprisingly, since everything is passed out as an object both in the IXamlMetadataProvider and CustomPropertyImpl classes, binding to value types is a bit more expensive because of boxing operations.

I'll provide the code for these two basic tests, if someone's interested.

Is this good for you ?

It may or may not be useful to you, depending on how much the non-NGENed startup is important for you, but also how much you rely on DataBinding.

I for one think that an added second to the startup to gain a rough 10% in binding speed seems a fairly reasonable deal, particularly when NGEN passes by afer a while to suppress this overhead.

Remember that an app only has 16.6ms to perform operations on the dispatcher between screen refreshes to maintain 60 Frames per second and keep a smooth user experience.

On an ARM tablet, added to other performance tweaks, this can overall make a difference.

Reducing apps startup time with Pre-JITing and NGEN on a Surface RT

Sat, 24 Nov 2012 21:13:00 -0600

TL;DR: The JIT can take over a third of the startup time of a managed Metro App, and using Native Image Generation (NGEN) can greatly improve the startup time of these apps. There is also a way to check for these native images to act accordingly.

A while back, I’ve had the chance to work with the guys that are behind the Pre-JIT feature of the CLR 4.5 for Metro Apps. Back then, I was only able to work on x86/x64 architectures, as ARM/Windows RT devices were not available.

Now that the Surface RT devices are available, we’re facing quite a few challenges in terms of code execution performance, and I’m going to discuss a few tips and tricks about the Managed Code JIT on Windows RT.

Profiling a slow starting app on a Surface RT

Running apps on the Surface can be troubling. Having an app that is useable after 16 to 18 seconds is definitely not acceptable, let alone the fact that the Splash Screen can disappear after 6 to 8 seconds.

Profiling such an app that starts slowly is very interesting, when looking a the Visual Studio profiler, where during these 17 seconds, about a third is spent in a “clr.dll” module in exclusive time (time spent only in this module and not its descendants). This is a very big number.

This time is actually spent in the JIT, where big methods tend to take more time to be JITed, sometimes on the UI thread, making the app sluggish.

This JIT phase is expected though, and is since .NET 1.0. Microsoft chose not to JIT metro apps on installation supposedly to improve the user's interaction flow with apps, and did not choose to make it in the cloud like the Windows Phone team did, starting from Windows Phone 8. The drawback of this approach is that managed code apps do have an extremely poor first launch experience, where the JIT kicks in every time.

The good news is that there are workaround for this slow startup, Pre-JIT and NGEN.

Pre-JITing applications

Pre-JIT is based on profiling how an app JITs code, then creating a file out of it that can be bundled with the final app package. In later startups of the app, that file is used of JIT code ahead of time, substantially improving the app’s startup time.

Yet, this technique is not the panacea, because it still requires the CPU to JIT code every time, preventing the rest of the app to use that CPU-time for some other useful tasks.

While this profile technique works like a charm on Windows 8 desktop, I’ve yet to notice any difference in the startup time of apps on Windows RT. I’m not sure if it’s the CPU that’s not powerful enough to JIT ahead of the normal execution path, or if it’s simply not used at all.

Interestingly, I’ve been able to generate that profile on a Surface device, but that’s pretty much it.

NGEN on Windows RT

Fortunately, apps are NGENed roughly after 24 hours. This technique, which has been around since .NET 1.0, has the ability to take managed code and generate a “native” image which is basically a fully JITed assembly that targets the current CPU architecture.

That same app that takes 17 seconds to start and be useable drops down to 12 seconds. This makes the startup a lot more interesting! (12 seconds is still not acceptable, but using other optimizations like using the 4 logical cores, that same app is now down to 8 second, which is a lot better)

This NGEN tool is ran as part of a “Maintenance Task”, located in the standard Windows Scheduler. It can be found when searching for “Schedule tasks” in the start menu, then under “Microsoft / Windows / .NET Framework”. Right clicking and selecting Run for both “.NET Framework NGEN v4.0.30319” and “.NET Framework NGEN v4.0.30319 64” will generate native images for applications that have been run at least once for what seems to be about 10 to 15 seconds.

On the Surface RT, generating these images can take quite some time depending on the size of the app. I’ve seen apps that take about 30 seconds to a minute to fully generate. Also note that there are space constraints, such as available free space. If your system drive has limited free space (such as below 1GB), NGEN will not generate anything.

Microsoft recommends running this tool by hand using a command line, but I’ve yet to see it work properly on a Surface RT device… Only running the scheduled task manually actually generates native images.

Checking for native images

Knowing that you’re running with or without native images can allow you to act differently to mitigate the terrible initial startup time.

The generated native images are located under the following folder:

%LOCALAPPDATA%\Packages\[AppID]\AC\Microsoft\CLR_v4.0_32\NativeImages

Testing for its presence is enough to guess it the app is running without JIT.

The following code can tell you this :

    private async Task IsNativeImage()
    {
        var source = Windows.Storage.ApplicationData.Current.LocalFolder.Path + "\\..\\AC\\Microsoft\\";
            
        try
        {
            await StorageFolder.GetFolderFromPathAsync(source + "CLR_v4.0_32\\NativeImages");
            return true;
        }
        catch (Exception ex) { }

        try
        {
            await StorageFolder.GetFolderFromPathAsync(source + "CLR_v4.0\\NativeImages");
            return true;
        }
        catch (Exception ex) { }

        return false;
    }

So when testing for your app’s performance, don’t forget to manually run NGEN and create a JIT profile !

Of Static Code Analysis, CA0001, WinMD files and C# Dynamic in Metro Style apps

Sat, 27 Oct 2012 12:42:00 -0600

tl;dr: This article is about working around an FxCop internal bug using the C# dynamic keyword, not exactly the way is was supposed to be used.

With the release of Windows 8 and WinRT, developing in .NET requires adding references to the new WinMD file format.

This format is a .NET assembly look-alike, so look-alike that old ILDASM builds can open them.

These files are only containing stubs, the definition of types that come from WinRT, which is developed using native C++ code.

WinMD files and Static Code Analysis

FxCop is working rather fine with WinMD files in Metro style apps, except for one interest case, when compiling the following code :

private static void SomeMethod()
{
   var b = new Button();
   b.Command = null;
}

Which fails with the following exception when analyzed by FxCop, using the “Microsoft Managed Recommended Rules”:

CA0001 : Rule=Microsoft.Reliability#CA2002, Target=App.MainPage.#SomeMethod() : The following error was encountered while reading module 'App3': Could not resolve member reference: [Windows, Version=255.255.255.255, Culture=neutral, PublicKeyToken=null] Windows.UI.Xaml.Controls.Primitives.ButtonBase::put_Command.

The reason for this is rather obscure though. It seems that FxCop is trying to analyse the declarative security attributes of WinMD exposed methods, but fails to do so… Which is ironic since these attributes cannot be used in Metro style apps :) But still, this is a multi-framework analysis engine.

Unfortunately, there seem to be no way to put an ignore directive, or supression attribute for this kind of internal error so fixing this, until this gets resolved by Microsoft, requires a bit of a hack.

A CA0001 workaround and the Dynamic keyword

The problem here is that FxCop tries to analyze the code, and finds the put_Command() method and tries to analyse it. The goal here is to get the code compiled and executable, while having FxCop ignore it.

Here’s how to do it :

private static void SomeMethod()
{
   #if DEBUG
   var b = new Button();
   #else
   dynamic b = new Button();
   #endif

   b.Command = null;
}

I do agree with you, really. This is not a particularly pretty code, and may not be that fast to execute, but it does the trick to still have Static Code Analysis running to catch all other possible code issues.

Having a dynamic variable in Release configuration, where FxCop is executed, allows to hide the call to put_Command() as a string generated by the C# compiler, while maintaining it original meaning.

Here's what actually generated by the compiler, to evade FxCop scrutiny :

object b = new Button();
if (MainPage.o__SiteContainer0.<>p__Site1 == null)
{
   MainPage.o__SiteContainer0.<>p__Site1 = CallSite>.Create(Binder.SetMember(CSharpBinderFlags.None, "Command", typeof(MainPage), new CSharpArgumentInfo[]
   {
      CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.None, null), 
      CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.Constant, null)
   }));
}
MainPage.o__SiteContainer0.<>p__Site1.Target(MainPage.o__SiteContainer0.<>p__Site1, b, null);

Having the code compiling using an actual static typing in Debug configuration leaves a bit of compile-time type checking, nonetheless.

There should be a connect entry for this soon, if you'd like to follow-up.

Happing dynamic hacking ! :)