asp.net project upgrade from 2.2 to dotnet 5 drastically reduced DI resolve speed

[lansman]

I'm not sure my problem related to Dependency Injection, AutoFac, EF Core or dotnet. But stack trace gives me Microsoft.Extensions.DependencyInjection so i tend to send it here.

I had dotnet core webapi 2.2 project. Have updated it and all libraries to dotnet 5.0 and got drastically reduced perfomance on all DI resolve actions, but the most important problem with slow resolving DbContext.

I have 2 DbContext: RW and RO. RW Is initialized with AddDbContext function with singleton DbContextOptionsReader. RO context is initialized with Scoped instance of its OptionsReader. It gives huge resolve speed difference. If register it as Singleton as well - speed becomes the same.

Startup.cs

public override void ConfigureCollection()
{
    ServiceCollection.AddSingleton<DbConnectionOptionsReader>();
    ServiceCollection.AddScoped<DbRoConnectionOptionsReader>(); // i need it to be scoped

    ServiceCollection.AddDbContext<DbContext>(SettingsRw); 
    ServiceCollection.AddDbContext<DbContextRo>(SettingsRo);

    private void SettingsRw(IServiceProvider provider, DbContextOptionsBuilder builder)
    {
        var dbOptionsReader = provider.GetRequiredService<DbConnectionOptionsReader>();
        builder.UseNpgsql(dbOptionsReader.ReadConnectionString(),
            opts =>
            {
               // some code
            });            
    }
    private void SettingsRo(IServiceProvider provider, DbContextOptionsBuilder builder)
    {
        var dbOptionsReader = provider.GetRequiredService<DbRoConnectionOptionsReader>();
        builder.UseNpgsql(dbOptionsReader.ReadConnectionString(), opts =>
        {
            // some code
        }
    }
}

public class DbConnectionOptionsReader
{
     // 2 dependecies only, both are Singletones
    public DbConnectionOptionsReader(IEnvContext envContext, IConfigurationRoot configRoot)
    {
        EnvContext = envContext;
        ConfigRoot = configRoot;
    }
    
    // skipped
}

public class DbRoConnectionOptionsReader : DbConnectionOptionsReader, IGetRoConnection
{
    // lot of dependencies
    public DbRoConnectionOptionsReader(IEnvContext envContext,
        IConfigurationRoot configRoot,
        IDoAllowRoRequest doAllowRoRequest,
        ILogger<DbRoConnectionOptionsReader> logger,
        IGetReplicationConnection getReplicationConnection,
        IGetRwForcer getRwForcer) : base(envContext, configRoot)
    {
        _doAllowRoRequest = doAllowRoRequest;
        _logger = logger;
        _getReplicationConnection = getReplicationConnection;
        _getRwForcer = getRwForcer;
    }
    
    // skipped
}

Test code:

[Route("api/Sandbox3/[action]")]
public class Sandbox3Controller : Controller
{
    private readonly IServiceProvider _serviceProvider;

    public Sandbox3Controller(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    // GET
    public IActionResult MeasureDbContextTime()
    {
        var dt1 = DateTime.Now;
        var _ = _serviceProvider.GetRequiredService<DbContext>().SystemParameter.Count();
        var dt2 = DateTime.Now - dt1;

        var dt11 = DateTime.Now;
        var __ = _serviceProvider.GetRequiredService<DbContextRo>().SystemParameter.Count();
        var dt22 = DateTime.Now - dt11;
        return Ok(
            new
            {
                DbRwTime = dt2,
                DbRoTime = dt22
            });
    }
}

Results:

dotnet 2.2 before upgrade

{
    "DbRwTime": "00:00:00.0079315",
    "DbRoTime": "00:00:00.0079183"
}

Perfect!

Upgraded 2.2 to dotnet5 project

{
    "DbRwTime": "00:00:00.0429624",
    "DbRoTime": "00:00:00.2241661" -- RO is very slow
}

RW x6 times slower!
RO x32 times slower!!

For experiment i created fresh dotnet 5 project and copypasted necessary parts for run (program.cs, startup.cs, both dbcontexts)

{
    "DbRwTime": "00:00:00.0198894",
    "DbRoTime": "00:00:00.0260551",
    "ResolveTime": "00:00:00.0000769"
}

RW x2 times slower than 2.2
RO x4 times slower than 2.2

But RO is still much better than my upgraded 5.0 project, 0.02 sec vs 0.2 sec.

I'd like to achive clean 5.0 results at least for the first time. So i have to understand why RO is so low on upgraded project.
I've measured traces via jetbrains dotpeak:

Here is comparison of stack traces of DbContext's Count() function

You can see fast method (upper) goes via TryAddCoreServices and ends pretty fast
Slow method (lower) goes via DynamicServiceProviderEngine and lasts so long.

Tell me please, in which conditions code may go 1 or 2 way?

I use Autofac and part of registrations goes via Autofac, another part - via IServiceCollection

dotnet 5.0.5 x64
Entity Framework 5.0.5
Autofac 6.1.0
Autofac.Extensions.DependencyInjection 7.1.0

Debug/Release project mode doesnt matter. I've tried downgrade to dotnet 3.1 and the problem is still there. So it occured during 2.2 -> 3.1 transition

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @eerhardt, @maryamariyan
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I'm not sure my problem related to Dependency Injection, AutoFac, EF Core or dotnet. But stack trace gives me Microsoft.Extensions.DependencyInjection so i tend to send it here.

I had dotnet core webapi 2.2 project. Have updated it and all libraries to dotnet 5.0 and got drastically reduced perfomance on all DI resolve actions, but the most important problem with slow resolving DbContext.

I have 2 DbContext: RW and RO. RW Is initialized with AddDbContext function with singleton DbContextOptionsReader. RO context is initialized with Scoped instance of its OptionsReader. It gives huge resolve speed difference. If register it as Singleton as well - speed becomes the same.

Startup.cs

public override void ConfigureCollection()
{
    ServiceCollection.AddSingleton<DbConnectionOptionsReader>();
    ServiceCollection.AddScoped<DbRoConnectionOptionsReader>(); // i need it to be scoped

    ServiceCollection.AddDbContext<DbContext>(SettingsRw); 
    ServiceCollection.AddDbContext<DbContextRo>(SettingsRo);

    private void SettingsRw(IServiceProvider provider, DbContextOptionsBuilder builder)
    {
        var dbOptionsReader = provider.GetRequiredService<DbConnectionOptionsReader>();
        builder.UseNpgsql(dbOptionsReader.ReadConnectionString(),
            opts =>
            {
               // some code
            });            
    }
    private void SettingsRo(IServiceProvider provider, DbContextOptionsBuilder builder)
    {
        var dbOptionsReader = provider.GetRequiredService<DbRoConnectionOptionsReader>();
        builder.UseNpgsql(dbOptionsReader.ReadConnectionString(), opts =>
        {
            // some code
        }
    }
}

public class DbConnectionOptionsReader
{
     // 2 dependecies only, both are Singletones
    public DbConnectionOptionsReader(IEnvContext envContext, IConfigurationRoot configRoot)
    {
        EnvContext = envContext;
        ConfigRoot = configRoot;
    }
    
    // skipped
}

public class DbRoConnectionOptionsReader : DbConnectionOptionsReader, IGetRoConnection
{
    // lot of dependencies
    public DbRoConnectionOptionsReader(IEnvContext envContext,
        IConfigurationRoot configRoot,
        IDoAllowRoRequest doAllowRoRequest,
        ILogger<DbRoConnectionOptionsReader> logger,
        IGetReplicationConnection getReplicationConnection,
        IGetRwForcer getRwForcer) : base(envContext, configRoot)
    {
        _doAllowRoRequest = doAllowRoRequest;
        _logger = logger;
        _getReplicationConnection = getReplicationConnection;
        _getRwForcer = getRwForcer;
    }
    
    // skipped
}

Test code:

[Route("api/Sandbox3/[action]")]
public class Sandbox3Controller : Controller
{
    private readonly IServiceProvider _serviceProvider;

    public Sandbox3Controller(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    // GET
    public IActionResult MeasureDbContextTime()
    {
        var dt1 = DateTime.Now;
        var _ = _serviceProvider.GetRequiredService<DbContext>().SystemParameter.Count();
        var dt2 = DateTime.Now - dt1;

        var dt11 = DateTime.Now;
        var __ = _serviceProvider.GetRequiredService<DbContextRo>().SystemParameter.Count();
        var dt22 = DateTime.Now - dt11;
        return Ok(
            new
            {
                DbRwTime = dt2,
                DbRoTime = dt22
            });
    }
}

Results:

dotnet 2.2 before upgrade

{
    "DbRwTime": "00:00:00.0079315",
    "DbRoTime": "00:00:00.0079183"
}

Perfect!

Upgraded 2.2 to dotnet5 project

{
    "DbRwTime": "00:00:00.0429624",
    "DbRoTime": "00:00:00.2241661" -- RO is very slow
}

RW x6 times slower!
RO x32 times slower!!

For experiment i created fresh dotnet 5 project and copypasted necessary parts for run (program.cs, startup.cs, both dbcontexts)

{
    "DbRwTime": "00:00:00.0198894",
    "DbRoTime": "00:00:00.0260551",
    "ResolveTime": "00:00:00.0000769"
}

RW x2 times slower than 2.2
RO x4 times slower than 2.2

But RO is still much better than my upgraded 5.0 project, 0.02 sec vs 0.2 sec.

I'd like to achive clean 5.0 results at least for the first time. So i have to understand why RO is so low on upgraded project.
I've measured traces via jetbrains dotpeak:

Here is comparison of stack traces of DbContext's Count() function

You can see fast method (upper) goes via TryAddCoreServices and ends pretty fast
Slow method (lower) goes via DynamicServiceProviderEngine and lasts so long.

Tell me please, in which conditions code may go 1 or 2 way?

I use Autofac and part of registrations goes via Autofac, another part - via IServiceCollection

dotnet 5.0.5 x64
Entity Framework 5.0.5
Autofac 6.1.0
Autofac.Extensions.DependencyInjection 7.1.0

Debug/Release project mode doesnt matter. I've tried downgrade to dotnet 3.1 and the problem is still there. So it occured during 2.2 -> 3.1 transition

Author:	lansman
Assignees:	-
Labels:	area-Extensions-DependencyInjection, untriaged
Milestone:	-

[davidfowl]

Can you update DI without updating EntityFramework and see if it reproduces? First thing that needs to happen here is to narrow down the dependency changes so you can tell if it's really DI that changed or somebody's usage of it that changed.

[lansman]

I've switched to dotnet 2.2 project. It has

• Autofac.Extensions.DependencyInjection 4.4.0
• Microsoft.Extensions.DependencyInjection 2.2.0
• Autofac 6.1.0
• Microsoft.EntityFrameworkCore 2.2.4

Before update

{
    "DbRwTime": "00:00:00.0195281",
    "DbRoTime": "00:00:00.0191790"
}

Updated Autofac.Extensions.DependencyInjection
4.4.0 -> 7.1.0, result:

{
    "DbRwTime": "00:00:00.0198892",
    "DbRoTime": "00:00:00.0193199"
}

Updated Microsoft.Extensions.DependencyInjection
2.2.0 -> 5.0.1, result:

{
    "DbRwTime": "00:00:00.0194775",
    "DbRoTime": "00:00:00.0192304"
}

You can see - still no problem.

[davidfowl]

So the issue can be moved to entity framework then?

[lansman]

I dont know.

For another experiment have switched to dotnet5 project downgraded to 3.1, have downgraded some of libraries also, got now:

• Autofac.Extensions.DependencyInjection 4.4.0
• Microsoft.Extensions.DependencyInjection 3.1.14
• Autofac 4.9.1
• Microsoft.EntityFrameworkCore 3.1.14

{
    "DbRwTime": "00:00:00.0261532",
    "DbRoTime": "00:00:00.2337475" -- problem is here
}

[lansman]

An another experiment.

I've got dotnet 5.0 project, but removed Autofac, project uses Microsoft DI only.

But problem is still here

{
    "DbRwTime": "00:00:00.0224191",
    "DbRoTime": "00:00:00.2410074"
}

So this is no Autofac-Microsoft DI some conflict issue. Its only Micrisoft DI one.

[davidfowl]

@lansman if you can make a project that has a minimal repro that shows that the DI container without autofac is a problem, that would be very helpful. Remove everything else from the project and get it running in a console application and share it on github with us.

[eerhardt]

I'm going to close this issue until a minimal repro can be produced. Feel free to re-open once you have one.