Document EnableServiceProviderCaching and UseMemoryCache configuration in EF Core

[Copilot]

Summary

This PR adds comprehensive documentation for EF Core's memory caching configuration options, specifically EnableServiceProviderCaching and UseMemoryCache. The documentation explains where these features are used, what the defaults are, and when to customize them.

What's Documented

EnableServiceProviderCaching

• Purpose: Controls whether EF Core caches internal service providers for improved performance
• Default behavior: Enabled by default (true) - service providers are cached and reused across DbContext instances with the same configuration
• When to disable: Strongly discouraged in most cases as it greatly slows down DbContext creation. Only consider for testing purposes when replacing services
• Performance impact: Better performance and lower memory overhead for applications that create many DbContext instances

UseMemoryCache / Memory Cache Integration

• Purpose: Configures the IMemoryCache used by EF Core for internal caching operations like query compilation and model building
• Default configuration: EF Core automatically configures IMemoryCache with a default size limit of 10240
• Cache sizing: Compiled queries have a cache size of 10, built models have a cache size of 100
• Customization: Call AddMemoryCache if you need to change the default size limits
• Clarification: IMemoryCache is not used for internal service provider caching (separate feature)

Documentation Changes

Updated Files

• entity-framework/core/dbcontext-configuration/index.md

  • Added both EnableServiceProviderCaching and UseMemoryCache to the DbContext configuration options table
  • Created new ## EnableServiceProviderCaching section with complete explanation of service provider caching
  • Created new ## Memory Cache Integration section explaining IMemoryCache configuration
  • Included code examples for ASP.NET Core DI scenarios
  • All content passes markdown linting rules

• entity-framework/core/performance/advanced-performance-topics.md

  • Added cross-reference link to Memory Cache Integration section for users learning about query caching

Documentation Structure

• Two main sections at ## heading level for clear organization
• Configuration options table updated with links to both sections
• Focused, accurate technical content based on reviewer feedback
• Clean formatting with proper list handling and paragraph flow
• Cross-references between related topics for better discoverability

Key Technical Details

• Service provider caching is enabled by default (important for developers to know)
• Disabling service provider caching greatly slows down DbContext creation
• Default memory cache size limit is 10240
• Memory cache and service provider caching are separate, independent features
• Proper guidance on when to customize each setting

Fixes #4855
Fixes #3102

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Document UseMemoryCache</issue_title>
<issue_description>Explain where it's used and what are the defaults</issue_description>

Comments on the Issue (you are @copilot in this section)

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Copilot]

@copilot Update the PR description with a summary of the changes

Updated the PR description with a comprehensive summary of the changes, including what was documented, the technical details, and the documentation structure.

[roji]

I'm conflicted about this sort of documentation. Yes, we have EnableServiceProviderCaching() as a public API, but this is something that I think we'd never recommend users ever actually use

So I'm not sure whether (and why) we should actually be documenting this - it runs the risk of pushing people towards an API they shouldn't use, it makes this doc page less useful (since it gets bloated with a non-useful API), and it creates more work for us (writing/reviewing the docs).

If we believe there are legitimate reasons for users to use this (I'm not really aware of any), then these should be documented here. There's just one sentence below: "for testing environments to ensure each test gets a fresh service provider when DbContext configurations change test-to-test", but I'm unclear as to when users would actually run into this: most settings don't require a different service provider, and those that do generally should be singleton options, so a new service provider is created anyway.

[AndriySvyryd]

Not documenting API to discourage its use is not a good strategy. We've seen that even pubternal API without XML docs will get used if the users this they need it. I think that explaining the appropriate use cases and downsides is valuable and is more likely to reduce incorrect usage.

[roji]

I agree that there should be good xmldocs (hopefully there are), but I don't think what you say holds for conceptual docs. A user sees xmldocs for an API once they're already using (or considering using) that API, so it's important for that to be there, and properly explain things. In contrast, conceptual documentation is how users discover an API: before they come to this "DbContext configuration" page, they're 99% unaware that EnableServiceProviderCaching even exists, and this PR will make them aware of it.
In other words, this effectively sends out a "marketing message" to tell users that this API exists, when they (almost certainly) didn't know it existed before.

The main question IMHO is whether you think this API makes sense for more than 1% of EF users - I don't see that it does. Assuming we agree on that, and this API is indeed a pit of failiure for the 99% case, we're doing our users a disservice by talking about it and making them aware of it. It may have been a mistake to even introduce this API, but then we'd be compounding that mistake by marketing it here, mostly in the name of an "all APIs should be documented in conceptual docs" rule.

An additional reason to not document this, is that every additional paragraph in the conceptual docs makes them less useful. We already have a history of falling into this, producing pages which are so huge that nobody even starts reading them - all the in the name of completeness/exhaustiveness, or the fear of being accused of having neglected to document something. I don't believe that's a good way to write docs.

If I've misunderstood and you actually think that disabling service provider caching is useful for some non-contrived, non-edge-casey scenarios, let me know (the above is written with that assumption).

[AndriySvyryd]

There's a valid scenario to use this in testing. We occasionally get questions about it, and I don't want to keep repeating the answer. I can move this to a new page under https://learn.microsoft.com/en-us/ef/core/testing/ to reduce length and visibility