IStartable in a child lifetime scope causes recompilation of factory delegates

[Tragetaschen]

Describe the Bug

An IStartable that depends on a Func dynamic instantiation recreates and compiles the factory delegate anew for every lifetime scope.
In the Gist, FactoryGenerator.CreateGenerator is called exactly once for LifetimeWithoutStartable and a total of four times—again once, but also once per lifetime scope—in LifetimeWithStartable.

Steps to Reproduce

https://gist.github.com/Tragetaschen/0f951b32cea3aaf98c1e9b83953dfcf8

Expected Behavior

I don't see a reason why the factory delegate cannot be reused for the startable and would prefer to not pay the expression creation, compilation and native code again and again for every child scope.

Dependency Versions

Autofac: 8.3.0

[Tragetaschen]

This looks like it's the underlying reason for #1448 - I finally found some time to further analyze this.

[tillig]

I don't really have anything new to add here that wasn't already on the other issue. If you have time for a PR, awesome; but generally I'd recommend sidestepping the problem and not using IStartable in a child lifetime scope at all.

[Tragetaschen]

While transforming my code:

It looks like this isn't tied to IStartable specifically, but how types and dependencies are organized across lifetime scopes

    public class Dependency { }
    public record FuncConsumer(Func<Dependency> Factory);

    [Fact]
    public void LifetimeWithConsumer()
    {
        var builder = new ContainerBuilder();
        builder.RegisterType<Dependency>();
        using var container = builder.Build();

        using var lifetimeScope1 = container.BeginLifetimeScope(c => c.RegisterType<FuncConsumer>());
        using var lifetimeScope2 = container.BeginLifetimeScope(c => c.RegisterType<FuncConsumer>());
        using var lifetimeScope3 = container.BeginLifetimeScope(c => c.RegisterType<FuncConsumer>());

        var c1 = lifetimeScope1.Resolve<FuncConsumer>();
        var c2 = lifetimeScope2.Resolve<FuncConsumer>();
        var c3 = lifetimeScope3.Resolve<FuncConsumer>();

        // These fail
        Assert.Same(c1.Factory, c2.Factory);
        Assert.Same(c1.Factory, c3.Factory);
        Assert.Same(c2.Factory, c3.Factory);
    }

This calls FactoryGenerator.CreateGenerator four times for essentially the same Func<Dependency>. Twice when resolving c1 and then once each for c2 and c3.

[tillig]

Some things to consider that may explain this, though possibly not to everyone's satisfaction:

There is no "equality" for dependency registrations.

There have been a couple of times in the past where folks have run into this (#722, #747) and it seemed confusing. For example:

var builder = new ContainerBuilder();

// These are two totally independent, not-equal registrations
// that will result in two different singletons being created.
builder.RegisterType<MyType>().SingleInstance();
builder.RegisterType<MyType>().SingleInstance();

var container = builder.Build();

// This will have two instances in it.
var instances = container.Resolve<IEnumerable<MyType>>();

While we have quite a bit of caching around types to try to speed up reflection lookups, we don't cache everything. For example, you'll notice we don't cache which constructor is selected for a given lifetime scope because the parameters provided may change.

That means it's pretty hard to cache much that isn't type specific because these two things are NOT EQUIVALENT:

var builder = new ContainerBuilder();
builder.RegisterType<FuncConsumer>();
builder.RegisterType<FuncConsumer>().WithParameter("Factory", () => new Dependency());

These things are also not equivalent, and there's no real way to test for parameter equality:

var builder = new ContainerBuilder();
builder.RegisterType<FuncConsumer>().WithParameter("Factory", () => new Dependency());
builder.RegisterType<FuncConsumer>().WithParameter("Factory", () => new Dependency());

The parameters provided there get baked into the delegate, making equality a challenging thing to calculate.

We also don't pass cached values from a child lifetime scope back up to a parent lifetime scope. Doing that is sort of a memory leak problem. "I registered this thing in my child lifetime scope but after doing that it consumed memory that wasn't disposed when I disposed of the scope! What gives?!"

So... if you are registering something in a child lifetime scope, we'll currently cache things like the set of constructors available but not the built delegates, because there's no real way to calculate equality across registrations, and you probably don't want an ever-growing cache of delegates that have every parameter specified for potential equality comparison.

It sounds to me like there could be a couple of potential answers here.

First, you could try InstancePerLifetimeScope so you can make one registration, have the delegate calculated once, but reuse it independently in each lifetime scope.

Second, you could look for ways to optimize the delegate generation to speed it up and have less impact on per-lifetime-scope registrations. The last time the FactoryGenerator code was truly looked at was close to 2020 so there may be new things that could be done in there to reduce allocations and/or improve performance.

[Tragetaschen]

I dabbled a bit with InstancePerLifetimeScope, but the real-world registrations weren't intentional enough to "just work" after moving them up one scope. It became whack-a-mole of which service resolution caused the delegate to be created in the "lower" scopes.

For the time being, I chose to introduce an additional transient factory service to replace the Func dependencies. Its Create method pretty much exactly does what the generated delegate would've done—resolving from the component context with the necessary typed parameters—, just not via Linq.Expressions.