IOptionsSnapshot is very slow

[NinoFloris]

This came up after a perf investigation on a recently refactored endpoint. Moving us back from IOptionsSnapshot to IOptionsMonitor knocked off ~100us, nothing else changed.

This option type of ours is fairly costly to create and looking into OptionsManager<TOptions> showed an obvious clue why we saw issues. OptionsManager does not just cache the instance for the duration of the DI scope but it also creates from scratch an instance through the factory per scope.

Looking through the docs this is vaguely alluded to (though there are contra-indicators) but after doing a search on SO and blogs on the subject most users seem to focus entirely on the 'you get a constant value during a scope/request' aspect of it.

As nobody (famous last words) seems to care whether it is entirely recreated my question would be:
Why doesn't OptionsManager<TOptions> cache the result of an IOptionsMonitor.Get call? (leaving out the backwards compatibility part for the sake of argument)

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

Issue Details

---

This came up after a perf investigation on a recently refactored endpoint. Moving us back from IOptionsSnapshot to IOptionsMonitor knocked off ~100us, nothing else changed.

This option type of ours is fairly costly to create, and looking into OptionsManager<TOptions> showed an obvious clue why we saw issues. OptionsManager does not just cache the instance for the duration of the DI scope but it also creates from scratch an instance through the factory per request.

Looking through the docs this is vaguely alluded to (though there are contra-indicators) but after doing a search on SO and blogs on the subject most users seem to focus entirely on the 'you get a constant value during a scope/request' aspect of it.

As nobody (famous last words) seems to care whether it is entirely recreated my question would be:
Why doesn't OptionsManager<TOptions> cache the result of an IOptionsMonitor.Get call? (leaving out the backwards compatibility part for the sake of argument)

Author:	NinoFloris
Assignees:	-
Labels:	area-Extensions-Options, tenet-performance, untriaged
Milestone:	-

[davidfowl]

Yes this is a known issue #42222. IOptionsSnapshot is currently a performance trap.

As nobody (famous last words) seems to care whether it is entirely recreated my question would be:
Why doesn't OptionsManager cache the result of an IOptionsMonitor.Get call? (leaving out the backwards compatibility part for the sake of argument)

Agreed that this implementation would have been more efficient. My only guess as to why it was done this way was because we had unified IOptions and IOptionsSnapsot implementations via the OptionsManager (though that's now changed in .NET 6).

The sad truth is that it would have been fixed if our own components were using it.

I'd be willing to take this change and see if there was any real impact not re-running factories per request. There are some very subtle differences but maybe worth the break.

cc @HaoK to see if he remembers why it was done this way.

[HaoK]

The original idea was:
IOptions is singleton and cached forever
IOptionsSnapshot is supposed to be scoped and recomputed per request (which is fine for some things, that don't involve config) (mostly exists for backcompat)
IOptionsMonitor is supposed to combine the ability to have options updates with caching semantics, change notifications and cache eviction

[HaoK]

If we are talking specifically about IOptionsSnapshot, that was intended to be really the no-caching you get a really new fresh instance on every scope, so it literally was intended to recompute everything on every request

[davidfowl]

Right. We should consider changing the implementation so that it caches the currently cached value so scoped services are a consistent view of the data but there's no need to recompute if nothing changes

[NinoFloris]

@davidfowl I see it's been placed in 7.0 is a PR for 6.0 still welcome?

[davidfowl]

Yes, if you send a PR, it can be done without adding public API (I believe).

[NinoFloris]

I agree, alright will be cooking it up.

[NinoFloris]

@davidfowl started work on it just now, practically the change is extremely simple * if * OptionsManager can take IOptionsMonitor instead of IOptionsFactory. This does mean an api compat error for the constructor, what's the policy on those? Alternatively I could duplicate the OptionsMonitor code into OptionsManager as that's as good as it gets with access to just IOptionsFactory.

runtime/src/libraries/Microsoft.Extensions.Options/src/OptionsManager.cs

Lines 17 to 27 in 57bfe47

	private readonly IOptionsFactory<TOptions> _factory;
	private readonly OptionsCache<TOptions> _cache = new OptionsCache<TOptions>(); // Note: this is a private cache
	/// <summary>
	/// Initializes a new instance with the specified options configurations.
	/// </summary>
	/// <param name="factory">The factory to use to create options.</param>
	public OptionsManager(IOptionsFactory<TOptions> factory)
	{
	_factory = factory;
	}

Ideally I'd also inline that silly cache (which is only used in OptionsManager) but it's a public type so I guess that's a no ;)

[davidfowl]

Or just make a new internal type so we don't need to change the public surface here. Call it OptionsSnapshot<T>