http://blogs.msdn.com/brada/archive/2003/08/05/50214.aspxWow – several hours of performance training for the CLR team today… One thing that came up was how to enabling writing fast foreach code by doing a better job of implementing IEnumerable… Apparently a while back there was some code that need to be superen-USCommunityServer 2.1 SP1 (Build: 61025.2)http://blogs.msdn.com/brada/archive/2003/08/05/50214.aspx#50215Mon, 11 Aug 2003 01:18:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:50215Frank HilemanI think anything very low level, such as a generic collection, can not allocate objects on every call as part of normal operation. I have noticed two other low-level places that persuade the programmer to allocate objects unnecessarily: delegate remove, and the recommended event design pattern. In the case of delegates, by convention one allocates a delagate to remove a delegate from a list of delegates. A static delegate can be used for this purpose, but this is not the convention. If the delegate remove function were overloaded, and could take as a parameter a different type of object, say a MethodInfo, there would be no need for the delegate allocation, and the syntax for hooking/unhooking events in C# could be simplified: button.Click -= button_Click; It would seem that removing a delegate is not done frequently, but this is not always the case. For example, the Application.Idle event must be unhooked as soon as it is fired (to prevent endless firing). So if you use this frequently, it must be hooked/unhooked all the time. The recommended event design pattern persuades the programmer to allocate an event args object before the event is even fired. The recommended pattern is to provide a virtual OnEventName function which takes an EvenNameArgs parameter as the second argument. Consequently, even if nothing is hooked to the event, the programmer must allocate the arg so that the OnEventName function can be called. If the OnEventName function is not overridden, and the event is null, the allocation/initialization is wasted. A static EventNameArgs object can be reused for this purpose, but this limits multithreading unless synchronization is also accounted for, and prevents recursion. Generally speaking, if events are potentiallly fired frequently, the recommended design pattern can cause a lot of wasted objects and CPU time, even when no events are acually fired. One solution to the allocation problem is to eliminate the convention of using an EventNameArgs object, and instead put the data right in the parameters of the delegate. In most cases there is little data passed. I think the event design pattern should be changed, so that events can be fired without allocating a single object, without making the code complicated.http://blogs.msdn.com/brada/archive/2003/08/05/50214.aspx#169975Wed, 30 Jun 2004 20:22:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:169975dotRobhttp://blogs.msdn.com/brada/archive/2003/08/05/50214.aspx#170218Wed, 30 Jun 2004 23:57:00 GMT91d46819-8472-40ad-a661-2c78acb4018c:170218Brad Abrams