i have a framework... : Silverlight

Building Functions vs. Building Expressions: Performance Comparison

fdumlao — Tue, 24 Feb 2009 04:47:35 GMT

Yesterday I posted an entry describing a method for building functions as opposed to building expressions to get a more succinct syntax, and in general a more functional approach. There was a touch of reflection in there though, so I wasn’t too sure what the performance would be like.

Even though the post was specifically about an alternative to building expressions, the commenter suggested that it was more efficient, based on his own benchmarks. I was shocked.

Not being the type to believe something without seeing it, I found myself compelled to write my own simple benchmark and the results were shocking.

Building functions is FASTER than building expressions. WAY faster. Let’s take a look:

The Code:

The function building method I created was this (again sorry for the formatting – I’m trying to make it fit):

   1:  public static Func<T, bool> BuildEqFuncFor<T>

   2:      (string prop, object val)

   3:  {

   4:      return t => t.GetType()

   5:          .InvokeMember(prop,

   6:              BindingFlags.GetProperty,

   7:              null,

   8:              t,

   9:              null) == val;

  10:  }

And the commenter suggested I use the approach where you build up an expression, and then compile it:

   1:  public static Func<T, bool> ExBuildEqFuncFor<T>

   2:      (string prop, object val)

   3:  {

   4:      var o = Expression.Parameter(typeof(T), "t");

5:

   6:      Expression<Func<T, bool>> expression =

   7:          Expression.Lambda<Func<T, bool>>(

   8:              Expression.Equal(

   9:                  Expression.PropertyOrField(o, prop),

  10:                  Expression.Constant(val)), o);

11:

  12:      return expression.Compile();

  13:  }

The Results:

I ran each method 1, 100, and 10,000 times and here were the results (in seconds):

It’s unbelievable how much faster the function building method ran, compared to creating an expression tree and compiling it. In fact, within 100 runs there was almost no change at all!

I looked into what was making the expression building function so long to create, and as I suspected it was the “Compile” method call that is used to turn the whole tree into a function. I changed the method to just return the expression and not compile it and re-ran the tests. It still took twice as long just to build the expression as it did to build an actual function.

If you think about it though, it makes sense. Compiling on the fly was never supposed to be considered a performant (yes I said “performant”) method of metaprogramming in C# and if you are going to use it, it would be wise to implement some caching to prevent the need to constantly build the same functions again and again.

Or, you can just build the functions directly.

C# Dynamic Function Factory

fdumlao — Mon, 23 Feb 2009 06:36:00 GMT

Building functions instead of expression trees.

The functional programming features of the latest versions of C# allow developers to harness a very expressive programming paradigm to solve challenges in new, elegant ways. Two of the very interesting new features are the “Func<>” delegate and the Lamda expression.

A Lamda expression is a simple expression that is interpreted by the compiler as either a delegate or an expression tree, depending on the Type called for in the given context. You see them used often in LINQ. For example:

   1:  var bostonPeople = people.Where( p => p.City == "Boston" );

Some time has been devoted in explaining how a LINQ query like the above can be created dynamically by building expression trees (see the excellent article: Creating Dynamic Queries in LINQ by Bill Wagner). While this approach to creating a Lambda expression dynamically is very powerful, some may find that it is far more than they need and instead could get by with a simpler implementation. Others may find it difficult to read or understand and therefore provides a challenge in maintenance.

One possible solution is to use the powerful new Func<> and a lambda expression to easily create a function on the fly. This solution is not quite as powerful as building an expression tree but in situations where it’s possible it will save quite a bit of code.

To demonstrate, how about a completely contrived example. Let’s say you have this object in your domain:

   1:  class Person

   2:  {

   3:      public string Name { get; set; }

   4:      public string City { get; set; }

   5:      public string State { get; set; }

   6:  }

and then let’s assume you need to have a way to return back a subset of a collection of “people” based on some criteria that won’t be known until runtime. We can create a factory that builds a function on the fly that we can pass into a LINQ method. Essentially what the “BuildEqFuncFor<T>” method does is build a Func<T, bool> that compares a given value against a named property of T. The signature of the built function is compatible with most LINQ query parameter expectations. (Please excuse the code formatting and naming conventions – I’m trying to fit it into this post.)

   1:  class FunctionFactory

   2:  {

   3:      public static Func<T, bool> BuildEqFuncFor<T>

   4:          (string prop, object val)

   5:      {

   6:          return t => t.GetType()

   7:              .InvokeMember(prop,

   8:                  BindingFlags.GetProperty,

   9:                  null,

  10:                  t,

  11:                  null) == val;

  12:      }

  13:  }

Now this factory only supports building functions that test for equivalency between some property of some object and a value, however more advanced functions could be constructed using the same concept.

We can now use this FunctionFactory to create a function on the fly and use it in a LINQ method to query our people collection. Let’s see what that looks like:

   1:  var personIsFromBoston =

   2:      FunctionFactory.BuildEqFuncFor<Person>("City", "Boston");

3:

   4:  var bostonPeople = people.Where( personIsFromBoston );

5:

   6:  if (bostonPeople.Any())

   7:      bostonPeople.ToList().ForEach(p => Console.WriteLine(p.Name));

Obviously this is a simple example but it could easily be expanded upon (and optimized) to create a more advanced function factory that could generate functions to solve problems beyond just creating dynamic LINQ queries. An issue you should take into account, is there is no compile time type checking so you should take care to handle cases where the type of the property doesn’t match the type of the value, or that the property even exists on the type provided at all.

As an interesting aside… this could be made even a bit more flexible by adding another function layer:

   1:  Func<string, Func<Person, bool>> personIsFrom =

   2:      s => FunctionFactory.BuildEqFuncFor<Person>("City", s);

3:

   4:  var bostonPeople = people.Where( personIsFrom("Boston") );

I hope you found this interesting, I look forward to your comments.

Silverlight Adaptive Streaming: How it works

fdumlao — Mon, 03 Nov 2008 16:11:12 GMT

Recently an announcement was made by Akamai that it was partnering with Microsoft to provide an Adaptive Streaming solution for Silverlight and IIS 7.0. Since I work in the online video industry I found the announcement very interesting, especially considering Move Network's previous announcement that it had formed a "Strategic Releationship" with Microsoft to provide this exact functionality.

I'm not sure if this represents the fruits of this relationship or not, but I can say that the two technologies are extremely similar in how they provide an almost "instant-on", high-definition stream of video to the client. Which brings me to the "meat" of this article - how the heck to they do that?

Specifically, you can see an example of what I'm talking about at www.smoothHD.com. You'll need Silverlight of course, but once you do you'll notice that the time it takes the video to begin playing is almost negligible and the quality is outstanding... unless you have a crappy connection... in which case you'll notice that it starts up quickly and has so-so to poor quality; which is by design. This is because Adaptive Streaming "adapts" to your bandwidth so that you get the best experience available to you. The thought is that it would be better for a client with slower access to get "something" rather than "buffering".

Step By Step - What makes this thing tick?

Let me start with the caveat that this is a high level overview of the technology - it's not perfect, but should provide you the jist of it. Now that I've said that, let's get started.

It all starts with encoding. In order to provide users with a stream appropriate for their bandwidth, the video needs to be encoded at various bitrates from low to very high quality. The more versions created the better the stream will be able to adapt.

Besides just creating several versions, the video needs to be "cut up" into many pieces. Most likely, this is done by cutting at particular times or frames in the video instead of cutting at particular sizes. So for example, if my video was encoded at 3 different bitrates (by the way 3 is far to few but makes my example easier) I might slice each of them at 5 second intervals ( I would probably make the interval shorter than that but again, this is an example). This way, the first slice of the video encoded using bitrate A would be 2kb, the first slice of the one using bitrate B would be 5kb, and the first slice of bitrate C would be 8kb. They are all different sizes but contain the exact same portion of video as their peers.

This is where Akamai comes in (although you could likely use any modern CDN). You need to ensure that access to these video "pieces" is fast, reliable, etc... So using a CDN like Akamai puts the files closer to the video consumer making delivery problems less likely. Once the video is on CDN, it's all up to the player.

The player bears the brunt of the work of making sure that the video stays smooth regardless of network conditions. The first thing that happens when the player starts up, is it grabs a manifest file containing information about all of those video pieces. It then makes a quick determination of the user's network bandwidth and grabs the first piece of video that is appropriate for the client's connection and begins playing. As that first piece begins playing, it looks closer at the bandwidth of the client and then adjusts the video quality when it grabs the next piece of video. It will continue to monitor the client's performance as it plays, and adjusting which piece of video to grab based on the information it has most recently gathered.

If you look at what it's doing here, you'll see that we aren't really talking about a "stream" but instead the player is playing small video files in a seamless sequence so that there is no interruption to the client. Because the video files are very small they load quickly and don't require waiting for "buffering". The video can begin playing when the first "piece" is downloaded (even before if the codec is one that allows for partial file playback). This also allows a client to "jump" to another spot in the video without having to wait for the player to re-buffer, because it just has to grab the small video file at the point you want to jump to.

One cool thing to note here; if you think about how the Internet works, you'll realize that there are many many more significant benefits to this than just smooth video for clients. As more and more clients watch a particular video, proxy caches all across the Internet will cache these small "pieces" of video files (as they tend to do with smaller files that are requested frequently). In essence these proxies become an extension of your CDN, except that it's free; because the proxies will serve up these small cached files without ever talking to Akamai or whatever CDN you are working with to deliver your video.

Hopefully this has provided some insight for those of you who wondered about this technology - I am excited to see more of this coming soon.