Performance regression in V9.1

[cjlotz]

Describe the Bug

When updating Autofac from v8.4 to v9.1 we have noticed a considerable degrade in the startup performance for our back-end .NET API server. Startup has increased from 22 to 34 seconds. The only change made to the code base were the following updates to Autofac in the Directory.Packages.Props as shown below:

We've noticed the efforts in #1478 to try and claw back some performance due to the recent changes to support AnyKey. Is there anything (besides downgrading) that we can do to get the performance back to v8.4 levels? We don't require AnyKey support and we want to stick with the latest Autofac updates.

Will it be possible to make AnyKey support an optional feature for those who do not require it and don't won't to incur the performance penalty for a feature they will not use? Or does isolating/opting out of the AnyKey feature cut too deep? Any other suggestions

Steps to Reproduce

• Update Autofac to the latest v9.1 release
• Startup .NET back-end API server
• Notice considerable slowdown in startup performance

[tillig]

There's nothing I'm aware of that would be impacting registrations, but, unfortunately, there's also nothing here that I can use to reproduce or test anything. "Start up .NET back-end API server" doesn't mean anything to me. You need to provide a reproduction in the form of something I can run (as indicated by the issue template).

Long startup times usually indicate you're registering a loooooot of stuff. In a lot of cases, when I've seen that, it's people doing assembly scanning and registration, and usually not being very specific about it - like "register everything in this whole assembly" sorts of things instead of registering only what's required.

I can't make AnyKey optional, sorry. This is one of those things that the base .NET folks unfortunately have forced on us by choosing to implement that in a way that we can't easily provide by "extending" something outside core Autofac. I tried hard, believe me, but it just didn't work. That's largely going to affect resolution time, though, not registration time, and there are a lot of hot-path optimizations around skipping AnyKey when it's not being used, so if I had to guess, that's more of a red herring.

Long story short: I can't reproduce it, and there's not enough information here to know exactly what is taking longer, so there's no real way to offer any help at all. I will leave this open for about a week as "feedback required" and if I don't get anything actionable I'll close it.

What I'd recommend: Get a profiler on your app on your end. Actually get data on what's taking longer so you can see if there are ways you can change your app or registrations. It could be as easy as being more specific in what you're registering, or it could be something more involved, but without real data, there's no place to start. If you have access to AI tools like Claude or Copilot, those things are REALLY good at this sort of stuff.

[cjlotz]

Thanks for the reply @tillig .

We totally understand that isolating AnyKey will be challenging/next-to-impossible and that your hand is forced in a way through .NET folks. We do have quite a few assembly scanning registrations for discovering different metadata aspects of our system that needs to be registered at application startup. Trying to do these aspects in a more delayed fashion will be difficult but might be possible - we will have to investigate this further.

I think what we are interested in is perhaps just an initial better understanding of what has changed to support AnyKey and how this negatively impacts existing registration patterns like assembly scanning. Based on your work in #1478, do you have any lessons/patterns that we should try to avoid where the performance hit of this with the new AnyKey support will be a lot worse than before.

We will also get cracking with profiling to try and pinpoint bottlenecks but if there are any hotspots to check/benchmarks/patterns that you can share beforehand that will be quite useful and assist us with evaluating our specific use cases.

Thanks again.

[tillig]

Unfortunately, no, I don't have any "gotchas" here. It should just work. I admit that we typically focus on resolution time performance over registration time since one affects runtime/ongoing requests and the other only happens one time in the whole application lifecycle. The best way to see "what was done" is to look at the commit history and pull requests. The vast majority was resolution time work to check - during resolution - if AnyKey is being used. We do a bit more caching of reflection items to speed this up, but it's not all calculated up front - it's "lazy populated" so it's determined on first use.

I'll go ahead and close this issue. Without something I can reproduce, I don't have anything to go on. If you do end up finding something, please file a new issue with some more specific information and I'd be happy to check it out. Even better, we do love issue-then-pull-request, if you can. :)