GrantRi's WebLog [MS] : Anonymous Methods

Anonymous Method Usage

grantri — Tue, 10 Aug 2004 21:18:00 GMT

So now that Beta 1 has been out and fairly widely availible for a while, how do you use anonymous methods?

When I was working on them I saw several contrived examples. I saw several that seemed more like abuses than legitimate uses. In my earlier posts I pointed out some of the problems the compiler has with 'optimizing' the code generated for anonymous methods and the methods that contain them. In many cases I simply had to brainstorm with other until we came up with a logical guess for the most likely use and a solution that worked well for that case while not overly penalizing the less common cases.

Are you a functional programmer that likes doing completions? Do you try and morph C# into something more like Scheme or Lisp? (I've seen code like this, but I've never felt comfortable writing code like this)

Are you more of a Pascal hacker that uses anonymous methods like nested methods? (I've done this a few times)

I haven't found a good name for this last style, so for now I'll call it the lazy style: where you use an anonymous method instead of real method just because it's faster. Like when a WinForms event handler only has one line of code, it just seems silly to write a whole method for that one line. I have also seen this taken to extremes: a WinForm with all the event handlers inlined as anonymous methods into the form's InitializeComponents method! In my mind this makes sense for small methods, but not big ones.

Lastly, how you found problems with anonymous methods that prevent your from using them where you want to? For example: the performance is too slow, too much memory overhead, etc.

--Grant

More thoughts on Iterators

grantri — Fri, 07 May 2004 07:35:00 GMT

So I had a short email exchange with a collegue about iterators. He mentioned that I should put in in my blog. Seemed reasonable, so here it is:

Subject: Iterator generated code

...
I'm looking at porting a hand-coded enumerator to use iterators (this is for a sample and maybe an article I have in mind to write about moving a production-quality collection to Whidbey)

I'm decompiling the generated code with the latest .net reflector, as my IL isn't really up to much.

My hand-written code tries hard to implement the full contract from the MSDN docs for IEnumerator, i.e. stuff like throwing InvalidOperationException if the underlying collection changes in both Reset and MoveNext and throwing in Current if it is past the last element.

I was wondering a couple of things

a) Will the past last element code get added to Current (i.e. state == -1)

b) Will a Reset implementation be added?
I can imagine that in many cases, the conditionals required to get to the yield return would be sufficient as a test in MoveNext and Reset, but I'm sure there are cases when it isn't.

However I guess this would require that any initialiser code for user state would have to move into the constructor for this to work, as docs for Reset specify that it throws if the collection has changed between creation and Reset
...

Subject: RE: Iterator generated code
a) No. The language designers specifically wanted the Current property to be inlineable, and NEVER to throw, even if it is accessed in an invalid state (before calling MoveNext, after MoveNext has returned false, when the collection has changed, etc.). The general reason is that most people use foreach (or some equivalent) and there should be no reason to punish them performance-wise fo rhte few people who try to call Current some other way.

b) Nope. Again Anders mainly thought that enumerables are meant to be throw-away object and should never be reset. He even pushed the generic form of IEnumerator to not have a Reset method (I think he would have removed it from the non-generic IEnumerator if it was possible).

I've often wished we had some nice syntax to say "run this code xyz for each iteration". The classic example is checking so see if the underlying collection has changed. Without such syntax the user has to write boiler plate code (hopefully just calling a single method) before or after every yield.

--Grant

Subject: RE: Iterator generated code
...
Would be good to position iterators as a performance-optimized foreach-server rather than a super-strict implementation of the IEnumerable contract.
...

This got me thinking some more about iterators. The frameworks often use an int as a version field to detect when a collection has changed. This seems like a bit of overkill and isn't 100% correct because it does suffer from wrap-around (although that is almost entirely impossible short of malicious code). So I was wondering how you could write 100% correct code and still use an iterator, and have it be clean and maintainable code.

My first thought was that you shouldn't need to increment the version all the time, only when there are live enumerator objects. My next thought was that to have maintainable code the version checking and throwing should be encapsulated into a single method. In C/C++ I would have used a macro to wrap up the version checking with the yield statement, but in C# I'm forced to just remeber to call my checker every place I yield.

Well, for the method that checks the version and throws, I have 2 choices: on the outer collection class, or as an anonymous method inside the iterator. Somehow the anonymous methods seems cleaner (and cooler) because it fits with the notion that an iterator effectively creates an anonymous class.

Now back to detecting changes. Instead of having an int, why not have an event that fires when the collection changes. The iterator could subscribe to it with an anonymous method as well. Then when there are no active iterators, there is little overhead (which is faster: a null check or an interlocked increment?).

So here's some quick slapped together pseudo-code:

public class SomeCollection { private event EventHandler CollectionChanged; private void OnCollectionChanged() { EventHandler h = CollectionChanged; if (h != null) h(this, EventArgs.Empty); } delegate void SimpleDelegate(); public IEnumerable<SomeType> MyIterator() { bool changed = false; EventHandler changedHandler = null; SimpleDelegate preCondition = delegate { if (changed) throw new InvalidOperationException(...); // Possibly some other validation code here??? }; changedHandler = delegate { changed = true; // Once it's changed, we don't need to know about future changes CollectionChanged -= changedHandler; changed Handler = null; }; try { CollectionChanged += changedHandler; ... yield return someValue; preCondition(); ... yield return someValue; preCondition(); ... } finally { if (changedHandler != null) { CollectionChanged -= changedHandler; changedHandler = null; } } } }

So what do you think? It's still not perfect because the event isn't subscribed to until the first call into MoveNext, which may happen significantly after the call to GetEnumerator. The only way around that would be to wrap the iterator itself with another method that created the changedHandler, subscribed it and then passed in the changedHandler/preCondition pair to the real iterator method. The down-side to that would be that if somebody called GetEnumerator twice on the same IEnumerable, both IEnumerators would share the same changedHandler/preCondition.

It still does seem like an awful lot of boiler-plate code. I might keep the notion of using an anonymous method as a way to pre and post conditions in an iterator, but using the int as a version for collections does seem to have fewer draw-backs (and a lot less boiler-plate code)...

--Grant

Remoting...

grantri — Sun, 18 Apr 2004 05:32:00 GMT

First off, I don't even pretend to have a good comprehension of how remoting works.

What I do know is that right now the compiler generated classes derive directly from Object, and somehow this is bad for remoting, instead they should derive from MarshalByReferenceObject. On the surface that is a very simple change, but it has some possibly serious performance implications.

Memory-wise, MBRO adds only a little bit. Certainly not enough to outweight the benefits of better remoting. The penalty comes when accessing fields of MBRO objects. The penalty is that every field access gets indirected through a method call. The method call is not needed when accessing fields off of the this pointer.

With iterators, this is a non-issue because the fields are only accessed internally off of the this pointer. Anonymous methods have the potential to be greatly impacted. It's bad enough that a local is now heap based, but making a local access into a method call would just supprise too many people.

So is there a way to have the best of both worlds: fast access and easy remoting? Here are the two ideas I've heard tossed around (well I guess one is mine):

Some keyword or syntax to specify whether a given anonymous method should be MBRO. Then you, the programmer, can clearly decide if remoting is more important than accessing locals quickly. The problem here is what syntax?
Base it on the containing object. This seems like a way of allowing you to decide, but without any extra syntax. The problem is that many classes derive from frameworks classes that have already made that decision (and probably for different reasons).

So here's your chance! Voice your thoughts and opinions. Do you have a better idea? Do you think I'm making a big deal over nothing?

--Grant

A good author writes better than a good developer

grantri — Tue, 30 Mar 2004 18:39:00 GMT

So here's a recent MSDN article that I actually had the chance of reviewing several months ago. They've done a much better job at capturing the good new stuff in C# than I could ever do.

http://msdn.microsoft.com/vcsharp/default.aspx?pull=/msdnmag/issues/04/05/c20/default.aspx

I do still have a few personal corrections:

I commented that the internal names that the compiler generates have changed and will probably change again, and so the article should probably just mention that the name is compiler generated and not give the actual name (those that care can run ILDASM and see for themselves), but they didn't listen. At least they did mention that is might change. For those of you who have the community drop you'll notice that the compiler generated names have changed from what's in the article.

I also commented that using the binary tree wasn't exactly the best example of iterators because of it's miserable performance. Yes it is clean and neat code, but if you have a binary tree with 5000 nodes and you foreach it a few times, you can watch your machine crawl as it is forced to spend more and more time in the GC rather than running your code. At least they mentioned this potential problem (see the last paragraph before the Partial Types section). Too bad my brain wasn't thinking and I got the numbers wrong. It should state, “approximately n/2 iterator instantiations, where n is the number of nodes in the tree.”

Also note the small paragraph on #pragma warning that now gives you line-level control over individual warnings!

--Grant

Some Cool New Features

grantri — Fri, 26 Mar 2004 22:03:00 GMT

I've been looking over some of my last few posts and they could easily come across as if I thought iterators and anonymous methods were the worst language features every added, and will never serve a good purpose. If anything I think the opposite (or else I wouldn't have spent so much time on them).

Second only to generics I think iterators and anonymous methods are the coolest features added to the C# compiler.

So then why have I been writing all this negative stuff? Well mainly because these guys are so powerful it's easy to write bad code and then blame it on the feature. My goal is to point out their weaknesses so that you as educated developers can write clean, neat, and efficient code, and not get burned. I believe in general these are both very powerful features, but like most powerful things they can be quite deadly if used improperly. Somehow I just don't feel like the MSDN docs are going to capture some of these gotchas in their 1/2 page topic on anonymous method or iterator syntax. Also I'm already starting to see bad habits and styles floating around and the features haven't even been officially released yet!

Well, if you've been itching to try them, we finally have an answer for you: Community Drops! If you attend VSLive! or have a MSDN Universal subscription, we're sending out or first community drop. One word of caution: this first release was definitely date driven, so there are known bugs, but it's a lot newer than the Alpha bits a few of you already have. I would personally recommend installing it on a 'throw away machine' (i.e. a machine you don't mind re-installing the OS on just to clean things up), but go out and try it. Hopefully the higher-ups will come up with a sane schedule for us releasing more frequent drops like this. Enjoy!

http://msdn.microsoft.com/vs2005/

--Grant

Anonymous Method Identity Crisis

grantri — Fri, 26 Mar 2004 01:04:00 GMT

Delegates, like strings, have done some work so that == behaves as expected, rather than as it should. A delegate can be thought of as a tuple of the instance (or lack-of-instance in the case of delegates to static methods) and the method it invokes. As long as those two items are the same, then the delegates are considered equal, regardless of whether or not there are 2 distinct GC objects holding that information. This neat little trick allows people to subscribe to an event, and discard that delegate instance. Then when they need to unsbsubscribe, they create a new delegate (to the same instance and method) and use that to unsubscribe.

Well that neat little coding pattern can burn you if applied to anonymous methods.

The easiest one to explain is the fact that the language spec does not require 2 anonymous methods with the same bodies to be implemented by the same method. So if you have the same anonymous method block in two places the compiler might or might not make them into the same method (our compiler doesn't right now).

The second problem is a little trickier to explain. Basically you have to remember that you don't directly control the instance of the delegate that points to an anonymous method. It could be static, it could be the same as the current method, or it could be something else entirely. If you really read closely my other posts, you can probably figure out how to read the code and determine what the compiler will do. First that is just plain error prone. It only takes one innocent edit to add or remove access to a parameter, a local, a field, or just about anything else, to change which instance the compiler will generate. Secondly it is not spelled out int eh language spec, and is thus free to change between versions and implementations.

Now you might be tempted to, “so what if I can't unsubscribe from some event.” Well the biggest problem is lifetime. As long as the anonymous method is subscribed to that event, it could be keeping your class alive longer than needed. That might then force you to use something like the allocation profiler to try and figure out why your memory characteristics suck.

So now that I've convinced everybody, here' the right way to do stuff. If you ever need the delegate that points to a given anonymous method in more than one place (like to unsubscribe), keep your own copy. Store the delegate in a local, a field, a static someplace before passing it off to anything else. Do not rely on delegate equivalence, use good old fashioned reference equality. Enjoy!

--Grant

Anonymous method (and Iterator) perf

grantri — Sat, 20 Mar 2004 05:09:00 GMT

probably a few of you hav asked how to make iterators and anonymous methods fast. Well hopefully if you understand how the compiler translates them, it should be relatively easy to optimize them. The first thing to remember is that for all practical purposes the C# compiler does not have an optimizer. Thus the code that you write is fairly directly translated into IL. The best way to optimize the IL is to optimize your code. In the case of iterators and anonymous methods, I've tried (and I think this was the language designers' intent as well) to make the transformations farily transparent, so that the programmer can easily write educated and efficient code while taking advantage of these great features. So here's my rules for making effecient anonymous methods and iterators (in no particular order):

Think carefully about which locals you use (a.k.a. capture). As soon as you touch a local in an anonyous method, that local becomes heap based and goes through an extra level of indirection (and prevent enregistering).
Think carefully about where locals are declared. In order to maintain proper scoping semantics the compiler creates a new heap object on entry of each scope that has captured locals. If you can move all the captured locals into one scope you'll probably get better perf. If possible move that scope 'inward' to avoid an GC object creation on a hot path (assuming the anonymous method is not on the hot path). If possible move that scope out of loops to avoid GC object creations on each iteration of the loop.
The captured locals do not have to be in the same scope as the anonymous method. The delegate that holds the anonymous method will be cached at the scope of the innermost captured local. Thus if the locals are outside of a loop, but the anonymous method is inside, that's OK.
Add extra scopes as hints to the compiler about lifetimes. For iterators, any scopes without a 'yield return' statement will be mostly left intact, including using real locals for everytihg in that scope instead of heap-based fields.
For iterators, if a try/finally block contains a yield statement, the finally block must be cloned from the MoveNext method into the Dispose method (so the same code is in two places).
For iterators, calling GetEnumerator twice is just as expensive as calling the original iterator method/property/indexer twice.
Iterators are designed to help amortize the cost of enumerations, so if you only need the first few elements, you don't need to pay the price for enumerating everything. Follow that pattern in your own iterators where possible.
Don't enumerate something twice when once will do. Most enumerations have another method to obtain the count of elements without iterating. So use that instead of iterating once just to count the elements, and then again to extract the values.
Anonymous methods make some algorithms clearer, and iterators tend to make more correct IEnumerable/IEnumerator implementations, but neither of them will never be as efficient as hand written code (or hand written assembler, but who has time for that anymore). So write well documented, clear, clean code, and then use a profiler to see if you need a speed improvement. And remember that a faster algorithm will probably trump any micro-optimizations in your code (like counting down instead of up to avoid that one extra opcode on th eloop test)

I'm sure I think of more later, but that's most of them for now. Enjoy, and feel free to correct me. I can't wait until you guys can get a newer build and see the stuff we've been working on for almost the last year.

--Grant

Anonymous Methods: Alternate Syntax

grantri — Thu, 18 Mar 2004 18:43:00 GMT

A few of you have suggested alternate syntaxes for anonymous methods or just complained about their syntax. Believe it or not syntax is very heavily discuess by the language design team (of which I am only an occasioanlly invited guest). Iterators almost got cut because they couldn't come up with a good syntax. So far I haven't seen a single syntax that the designers didn't at least glance at. They wanted anonymous methods to be light-weight, but still clear and mostly understandable. I guess there weren't enough scheme or lisp people in the design group because most of those syntaxes dead ended on picking the right open and close characters that would work. Square brackets were out because of arrays; angle brackets we're already overloaded between shifting, comparisons, and generics; parenthesis we're too ambigous; that left curly brackets. Once they decided on curlies, it looked too much like a method body to not have the parameter list on the outside. The last decision to be made was 'keyword or no keyword'. Hate me if you like, but I was in the keyword camp. I just think the keyword makes things cleaner (not to mention prevents some ambiguities in the grammar). But then they had to choose a keyword. 'delegate' is a good clear word and I think it helps newbies understand what's going on a little. My only complaint is that it's so darn long! I wish we could have found an equally expressive and unambigous keyword that was only 2 or 3 characters long... :(

--Grant

Anonymous Method Part 2 answers

grantri — Wed, 10 Mar 2004 03:12:00 GMT

I think the winner is Jerry Pisk. His final comment I think does the best job of explaining, what I was trying to explain. Thanks Jerry. I also partially agree with Jerry's first comment, namely anonymous methods can be confusing and lead to poor readability...(read more)

Anonymous Methods, Part 2 of ?

grantri — Tue, 09 Mar 2004 02:07:00 GMT

A lot of people seem to have trouble grasping how anonymous methods affect the lifetimes of locals. SO hopefuly I can clarify that a little. Previous to anonymous methods, the lifetime and the visibility of a local were identical for all practical purposes. Because of the visibility restrictions, there was no way to tell if a loop was sharing the same instance of a local or using a new instance of a local. Example:

void SomeMethod()
{
    int outer = 0;
    for (int i = 0; i < 10; i++)
    {

    int inner = i;
        Console.WriteLine("outer = {0}", outer++);
        Console.WriteLine("i = {0}", i);
        Console.WriteLine("inner = {0}", ++inner);
    }

}

Here we have 3 locals: outer, i, and inner. Conceptually there is one instance of outer, and i for each invocation of SomeMethod. I think everybody would agree to that so far. Now comes the tricky part: there is conceptually a unique instance of inner for each iteration of the loop or each entry into the containing scope. That means that in this example there are 10 different instances of inner. However, because none of the lifetimes overlap, there is no way to detect this, and the C# compiler uses the same slot for all instances. The runtime might even use the same register for each instance. As soon as you add anonymous methods to the mix, then lifetimes do have the ability to overlap, and suddenly your code can percieve the different instances. As an example, we'll modify the above code to not write out the variables directly, but instead create 10 anonymous methods (one for each loop) that does the same thing. We'll run each anonymous method twice: once inside the loop when it is created, and once after the loop has finished.

delegate void NoArgs();

void SomeMethod() { NoArgs [] methods = new NoArgs[10]; int outer = 0; for (int i = 0; i < 10; i++) { int inner = i; methods[i] = delegate { Console.WriteLine("outer = {0}", outer++); Console.WriteLine("i = {0}", i); Console.WriteLine("inner = {0}", ++inner); }; methods[i](); } for (int j = 0; j < methods.Length; j++) methods[j](); }

Now test yourself and see if you can predict the actual output. Just remember that the number of instances hasn't changed, only their lifetimes. The first time we run the anonymous methods, we get the exact same output as before: outer counts from 0 to 9, i counts from 0 to 9, and inner counts from 1 to 10. Now the second time we run the anonymous methods things might be a little supprising. outer continues counting from 10 to 19, i is stuck 10, and inner looks like it is counting from 2 to 11! If you think you know why, post a comment, or email me. If this is so simple that I should stop wasting my time and yours, let me know. Otherwise, I explain the whys and hows in my next few posts.

Here's the acutal output:

outer = 0
i = 0
inner = 1
outer = 1
i = 1
inner = 2
outer = 2
i = 2
inner = 3
outer = 3
i = 3
inner = 4
outer = 4
i = 4
inner = 5
outer = 5
i = 5
inner = 6
outer = 6
i = 6
inner = 7
outer = 7
i = 7
inner = 8
outer = 8
i = 8
inner = 9
outer = 9
i = 9
inner = 10
outer = 10
i = 10
inner = 2
outer = 11
i = 10
inner = 3
outer = 12
i = 10
inner = 4
outer = 13
i = 10
inner = 5
outer = 14
i = 10
inner = 6
outer = 15
i = 10
inner = 7
outer = 16
i = 10
inner = 8
outer = 17
i = 10
inner = 9
outer = 18
i = 10
inner = 10
outer = 19
i = 10
inner = 11

--Grant

Anonymous Methods, Part 1 of ?

grantri — Fri, 06 Feb 2004 07:29:00 GMT

Although I was involved in many of the language design meetings, I don't think I can claim much of the credit for the actual design of the feature in the language spec. There were a few technical gotchas that I discovered and proposed solutions to, and I'll try to remember to point them out as appropriate.

First of all, although anonymous methods can be compared to several other features in several languages I think they are different enough to really be classified as their own beast (if somebody does know of another language that really does have something like anonymous methods please enlighten me). Functional programmers will be sad when they learn that the captured locals are read/write. Anonymous methods are different from regular delegates because of their ability to capture a locals. They aren't exactly anonymous classes (although with careful knowledge of how the compiler works you could use them as such).

So what are anonymous methods? It is a way of writing an unnamed nested method that, just like most languages that have nested methods, allows access to all of the outer method's locals and parameters, including the 'this' parameter. Here's where we hit the first gotcha. In order to allow access to the outer method's locals and parameters we have to move them off of the stack onto the heap so they can live beyond the method execution and still be verifiable (no pointer arithmetic or passing of stack frame pointers into nested methods). Well for starters we can't move reference parameters onto the heap, hence the restriction that ref or out parameters cannot be captured (used inside anonymous methods). If you do need to do something like that the suggested pattern to make the code explicitly perform copy-in and/or copy-out semantics by assigning to or from a local of the same type.

Example:

void SomeMethod(ref int ri)
{
    ...
    delegate {  ri++; } // This use is illegal because some users might expect
    // the reference to outlive the method, and thus whenever they invoke the
    // delegate some integer someplace gets incremented
    int copy_of_i = ri;

    ....
    delegate { copy_of_i++; } // This is legal because now the programmer is
    // forced to realized the delegate can't mess with ri
    ...
    // Then if the delegate is invoked, or copy-out is required


    ri = copy_of_i;
}

Now to complicate things even further, we have to remember that the 'this' pointer of structs is passed as if it was a reference parameter, that is why anonymous methods inside structs cannot access any instance members, while their counterparts inside classes can. Again the suggested pattern to do a copy-in or copy-out as needed. The language designers briefly toyed with the compiler automatically injecting the copy semantics, but them what happens when the real struct is modified on another thread? Suddenly the user is able to perceive the difference between passing-by-reference and copy-in/copy-out. Then there was also the question of where should the copy occur, and what happens when the delegate/method is invoked long after the outer method has returned, then there is no place to do the copy-out! In the end we figured this was the safest route because it made it crystal clear what the compiler was going to do and the programmer would be forced into thinking about when and if a copy-out was needed. I think that was probably my biggest contributions to anonymous methods.

Now earlier I mentioned that the compiler moves all the locals from the stack onto the heap. As you might have already guessed this involves allocation of a GC object. The compiler works very hard to preserve the semantics of your original method, and as such tries to only create things when needed, but still in a very predictable manner. To find out where an object will be created, simply look at the scopes. Start at the outermost scope of the method (the open curly), and then work inward with this simple rule: if this scope contains any captured locals, the compiler will remove the local from the generated method and replace all the captured locals in that scope with fields in a new class. The new class instance will be created on each entry into that scope (so that loops like for, foreach, do, while, will get new locals for each iteration, but gotos within a scope will not). So if you have 5 scopes each with one or more captured locals, you'll get 5 display classes. So choose carefully which locals you capture and where they are declared. In the outer method accessing a captured local becomes a single indirection through a display class. From inside the anonymous method the local is often accessed as a member of 'this'. The other performance gain that the compiler strives for is to eliminate extra delegate creations. To accomplish that the compiler creates another local to cache the created delegate, thus if your anonymous method appears in the middle of a tight hot loop, as long as you don't capture any locals inside the loop, the constructed delegate will be cached outside the loop, and thus will only be created once and then successive loop iterations will only re-use the created delegate.

So I guess my final point for this post will be be careful when writing new code. Anonymous methods can be very very useful, and make certain programming tasks very easy, but “with great power comes great responsibility“ because these wonderful anonymous methods, if used improperly can literally kill performance...

--Grant