A look under the hood of a C# decompiler.
Decompiling C# (async/await)
community.sharpdevelop.net
Decompiling C# (async/await)
1–10 of 29 posts
Re: Decompiling C# (async/await)
#2Inside every language there is a minimal language with all the syntactic sugar translated into a subset of the language.
e.g. the C# compiler turns "var a = 3;" into "int a = 3;" It turns anonymous lambdas into methods with generated names (i.e turns one line of code into 3-4 lines), and makes classes with constructors that do the environment capture if needed. It turns "yield return" generator methods into objects that have state.
While async/await is a cool feature and is worth using, it is worth noting the up trend in complexity of generated code – and ansyc/await generates significantly more code in the simpler language without this feature than previous new features did.
How much code does an await statement give rise to? it looks like about 40-50 lines to me.
Re: Decompiling C# (async/await)
#3Inside every language there is a minimal language with all the syntactic sugar translated into a subset of the language. e.g. the C# compiler turns "var a = 3;" into "int a = 3;" It turns anonymous lambdas into methods with generated names (i.e turns one line of code into 3-4 lines), and makes classes with constructors that do the environment capture if needed. It turns "yield return" generator methods into objects t…
Yes,for each await it basically generates a state machine. It's pretty crazy to think how much code you don't have to write by using "await".
Re: Decompiling C# (async/await)
#4Inside every language there is a minimal language with all the syntactic sugar translated into a subset of the language. e.g. the C# compiler turns "var a = 3;" into "int a = 3;" It turns anonymous lambdas into methods with generated names (i.e turns one line of code into 3-4 lines), and makes classes with constructors that do the environment capture if needed. It turns "yield return" generator methods into objects t…
Yes,for each await it basically generates a state machine. It's pretty crazy to think how much code you don't have to write by using "await".
"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.
Re: Decompiling C# (async/await)
#5Inside every language there is a minimal language with all the syntactic sugar translated into a subset of the language. e.g. the C# compiler turns "var a = 3;" into "int a = 3;" It turns anonymous lambdas into methods with generated names (i.e turns one line of code into 3-4 lines), and makes classes with constructors that do the environment capture if needed. It turns "yield return" generator methods into objects t…
You need to compare it to the alternatives. For instance how much IL will be procuded from creating Tasks with Continuations?
Async/Await makes it easier to write asynchronous code in a traditional linear manner, it's easy to shoot yourself in the foot but it's just as easy with the alternatives.
Here's an article that I wrote a while back on what Async & Await generates: http://blog.filipekberg.se/2013/01/16/what-does-async-await-...
Re: Decompiling C# (async/await)
#6Inside every language there is a minimal language with all the syntactic sugar translated into a subset of the language. e.g. the C# compiler turns "var a = 3;" into "int a = 3;" It turns anonymous lambdas into methods with generated names (i.e turns one line of code into 3-4 lines), and makes classes with constructors that do the environment capture if needed. It turns "yield return" generator methods into objects t…
It is neat that C# has some standard macros defined. It would be nicer if it was more explicit what is going on behind the scenes. I would love to see the equivalent of c-macro-expand. [0]
Also, although it is possible to extend C# using stuff like custom linq providers, [1] I still prefer lisp style macros.
[0] http://www.linuxjournal.com/article/2821 [1] http://msdn.microsoft.com/en-us/library/bb546158.aspx
Re: Decompiling C# (async/await)
#7Inside every language there is a minimal language with all the syntactic sugar translated into a subset of the language. e.g. the C# compiler turns "var a = 3;" into "int a = 3;" It turns anonymous lambdas into methods with generated names (i.e turns one line of code into 3-4 lines), and makes classes with constructors that do the environment capture if needed. It turns "yield return" generator methods into objects t…
It is neat that C# has some standard macros defined. It would be nicer if it was more explicit what is going on behind the scenes. I would love to see the equivalent of c-macro-expand. [0] Also, although it is possible to extend C# using stuff like custom linq providers, [1] I still prefer lisp style macros. [0] http://www.linuxjournal.com/article/2821 [1] http://msdn.microsoft.com/en-us/library/bb546158.aspx
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)
Re: Decompiling C# (async/await)
#8Earlier quoted context omitted.
It is neat that C# has some standard macros defined. It would be nicer if it was more explicit what is going on behind the scenes. I would love to see the equivalent of c-macro-expand. [0] Also, although it is possible to extend C# using stuff like custom linq providers, [1] I still prefer lisp style macros. [0] http://www.linuxjournal.com/article/2821 [1] http://msdn.microsoft.com/en-us/library/bb546158.aspx
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)
Surprisingly, you don't have to wait for Roslyn.
The technique exists now [0]. It is kind of a pain to use and seems kind of dangerous to use as a web app. But it is there. I messed with this a few years ago.
[0] http://stackoverflow.com/questions/3111190/compiling-net-cod...
Re: Decompiling C# (async/await)
#9ILSpy is probably one of the best utility programs I have ever used... It has saved me countless times from poorly documented API's and helps me work around countless bugs in third party libraries.
Re: Decompiling C# (async/await)
#10About the only time that you have to be really careful with stuff like this is if you're writing something that's super sensitive to GC pauses, such as an XNA game. In those cases, yield return, linq, lambdas, some foreach loops will all generate short lived objects that will cause the GC to kick in more often. So if you're doing that in every update loop you could end up with performance issues. And even that is only on some platforms, as the desktop GC does a great job of dealing with short term garbage.
But in most cases such as ASP.NET MVC actions, or doing an API call in a desktop app, the maintenance and high level code simplification you can get by using these techniques far outweighs the low level "cost" of the code generated by the compilers.
It's good to know what's going on under the covers though.