Reduce Heap allocations

[Mrnikbobjeff]

I have found several instances where we can eliminate heap allocations via simple changes such as iterating over an IList via for loop to avoid the boxing allocation for the enumerator or calling ToString on value types to be passed of to string formatting. On further investigation we are allocating a ton of method group to delegate conversions. From the C# specification section 6.6, describing the run-time evaluation of a method group conversion:
A new instance of the delegate type D is allocated. If there is not enough memory available to allocate the new instance, a System.OutOfMemoryException is thrown and no further steps are executed.

The section for anonymous function conversions (6.5.1) includes this:

Conversions of semantically identical anonymous functions with the same (possibly empty) set of captured outer variable instances to the same delegate types are permitted (but not required) to return the same delegate instance.
And we have lots of places where these conversions happen. If wanted I would love to optimize these problems, the code will stay the same semantically but allocate less.

[miloush]

As has been the case in the CoreCLR repo, I think it would be good to know how much impact do the suggested optimizations have.

The promise of semantically equivalent code should also be careful. Iterating using for vs foreach can have different behavior, calling ToString can change the culture used for formatting etc.

[Mrnikbobjeff]

@miloush can you give an example of boxed value type toString which would print differently if you call toString on the unboxed value? Because this is essentially what I am understanding from ToString changes the culture. Whether I first box my value type and then call toString should never change the culture. For the first example, the only instance I could think of where that would be the case would be a custom class which implements IList where the enumerator has side effects, which is not the case for all default IList implementations. If you have an enumerator with side effects you also have way bigger problems than the boxed enumerator.
I can set up a few sample benchmarks comparing the allocation of some optimized vs unoptimized functions

[Mrnikbobjeff]

I created a small solution with some benchmarks referring to cases present in the source where the allocations are visible, e.g. enumeration via interface enumerator etc. See BenchmarkingSolution and select the cases where you want to see the cost of doing thins such as ennumerating via IEnumerable.