Option code optimizer

[declard]

Imagine there is a higly loaded application making heavy usage of the Option types, and there is a monadic code with all those FlatMaps and Maps, or even worse - linq syntax expression, invoked in a loop somewhere. That brings pressure on the GC as closures and anonymous objects are continiously created.

What if

(a, b, c) =>
    from aprime in a
    from bprime in b
    from cprime in c
    where Predicate(aprime, cprime)
    select Combine(aprime, bprime, cprime)

transformed automagically into something like

(a, b, c) =>
{
    if (!a.HasValue) return default;
    var aprime = a.GetValue();
....
    if (!Predicate(aprime, cprime) return default;
    return Combine(aprime, bprime, cprime);
}

when passing it as an expression to a special function?

I understand this might be not a frequent case and one would say "use low-level things in this case", but anyway, should an optimized Option code generation be considered as an appropriate feature for this library?

I have my own small library (which nobody really knows about) with maybe, either, CPS, collection extensions and so on, and there's a code there for doing what I've just described (not published anywhere yet), I decided it would be more productive to contribute here.

[nlkl]

Hi!

I am certainly not against performance improvements, insofar we can keep them hidden from the public API.

Could you elaborate a bit on how you would introduce such optimizations, so I can better evaluate the pros/cons?

Thanks!

/ Nils