Decompiling C# (async/await) (opens in new tab)

When did they introduce caching for lambdas? I've been caching them by hand since I used to see them pop up in CLR Profiler all the time. Is it unable to cache lambdas constructed in member functions because it can't be sure they don't close over 'this'?

A for loop will have bounds checking removed, for one. Also, the JIT does better inside single method bodies. Compare:

  1: for(i = 0; i < arr.Length; i++) sum += arr[i];
  
  2: foreach(var x in generate(count)) sum += x;

In the first case, you end up with a small, relatively tight loop (the machine code has a lot of extra stuff I don't quite understand).

In the second case, you're literally doing a virtual call (and I don't think the CLR inlines interface calls) to get_Current() in a loop, followed by MoveNext(). So there's 2 function call overheads, not to mention the actual code that get_Current and MoveNext have.

Here's the sample program[1]. I get about 600% runtime for the enumerable version versus the array. Given all the extra work, I'm sorta impressed it's only 6x. The 32-bit JIT is a bit slower doing the array method than the 64-bit, which surprises me. Here's the code for the loops[2].

1: http://pastebin.com/GAg3RiNx

2: http://pastebin.com/index/a1eC8sX9

A "yield return enumerable" is "delay executed" so evaluating it multiple times causes the yield-return execution to occur at every evaluation (if you haven't taken care to ToArray() or ToList() it). Do something like:

  var myBytes = GetMyBytesItr();
  for (var i = 0; i < myBytes.Count(); ++i)
  {
    ProcessByte(myBytes.ElementAt(i));
  }

and you'll be in a world of hurt especially if GetMyBytesItr() allocates a memory buffer. Count() causes the "get the bytes data" action to occur, as does every iteration of ElementAt(). Now I'm not saying this is definitely what you were experiencing, but it's a common pitfall. Also, using ElementAt() for each iteration is, of course, completely contrived for this example (you'd want to foreach instead which would cause only one execution of the "get the bytes data" action).

Yeah. I consume the munged IL that comes out of their transform pipeline (though for complex reasons, I don't use all of it - some of their transforms are destructive in ways that aren't helpful, or I'd have to undo them) which saves me the trouble of reimplementing things they already figured out, like how to transform most branch/jump patterns into if statements and while loops.

I could generate JS from raw IL (and other projects like Volta did just that) but ILSpy gives me a huge head start in terms of producing JS that actually looks like what you'd write by hand. For loops instead of while loops, switch statements instead of cascading ifs, etc.

Personally I think the Async/Await model is too limiting. E.g. lets talk about this:

    var result = await client.GetStringAsync("http://msdn.microsoft.com");

From the perspective of the caller, that code is still blocking. It solves the problem of threads being blocked, but that's only one of the problems you have.

The real and more complete alternative would be to work with a well designed Future/Promise framework, like the one in Scala [1] which is also usable from Java [2]. Doing concurrent computations by means of Futures/Promises is like working with Lego blocks.

Let me exemplify with a piece of code that's similar to what I'm using in production. Lets say that you want to make 2 requests to 2 different endpoints that serve similar results. You want the first one that completes to win (like an auction), but in case of a returned error, you want to fallback on the other one (type annotations and extra verbosity added for clarity):

    val url1 = "http://some.url.com"
    val url2 = "http://other.url.com"

    // initiating first concurrent request
    val fr1: Future[Response] = client.get(url1)

    // initiating second concurrent request
    val fr2: Future[Response] = client.get(url2)

    // the first fallbacks on the second in case of error
    val firstWithFallback: Future[Response] =  
      fr1.fallbackTo(fr2)

    // the second fallbacks on the first in case of error
    val secondWithFallback: Future[Response] = 
      fr2.fallbackTo(fr1)

    // pick a winner
    val finalResponse: Future[Response] = 
      Future.firstCompletedOf(firstWithFallback :: secondWithFallback :: Nil)

    // process the result
    val string: Future[String] = finalResponse.map(r => r.body)

    // in case both endpoints failed, log the error and 
    // fallback on a local copy
    val stringWithFallback: Future[String] = string.recover {
      case ex: Exception =>
        logger.error(ex)
        File.read("/something.txt")
    }

Given an HTTP client that's based on NIO, the above code is totally non-blocking. You can do many other crazy things. Like you can wait for several requests to complete and get a list of results in return. Or you can try the first url and if it fails, try the second and so on, until one of them succeeds.

In the context of web apps, you can prepare Future responses this way and return them when they are ready. Works great with the async responses support from Java Servlets 3.0. Or with a framework such as Play Framework 2.x you can simply return Future[Response] straight from your controllers [3]

[1] http://docs.scala-lang.org/sips/pending/futures-promises.htm...

[2] http://doc.akka.io/docs/akka/snapshot/java/futures.html

[3] http://www.playframework.com/documentation/2.1.0/ScalaAsync

Yep. The C# design attitude seems to be that the compiler-writers have the ability to define such macros, but the C# compiler users don't. Compare with F#.

Though that may change with C# 5 and Roslyn (http://en.wikipedia.org/wiki/Microsoft_Roslyn compiler as a service)

"yield return" also makes a state machine, but a simpler one. I like async/await, but I am aware of the steep upward trend in internal complexity of these features.

IMHO this means that the fruit of these features are no longer so low-hanging.