Update AnalyzersExtensions and SettingsHelper to use cached JsonValue objects where possible

[bjornhellander]

Partial fix for #3634

The primary change is to use the SourceTextValueProvider cache in CompilationStartAnalysisContext to reduce the number of times the settings file is parsed. Code fix providers and some tests still use overloads of GetStyleCopSettings which does not use the cache.

[codecov]

Codecov Report

Merging #3642 (2abbe2a) into master (ccaac20) will increase coverage by 0.00%.
The diff coverage is 95.69%.

❗ Current head 2abbe2a differs from pull request most recent head 308a2db. Consider uploading reports for the commit 308a2db to get more accurate results

Additional details and impacted files

@@           Coverage Diff            @@
##           master    #3642    +/-   ##
========================================
  Coverage   93.26%   93.26%            
========================================
  Files        1079     1079            
  Lines      113737   113859   +122     
  Branches     4027     4030     +3     
========================================
+ Hits       106072   106186   +114     
- Misses       6630     6636     +6     
- Partials     1035     1037     +2     

[bjornhellander]

Seems to also be a partial fix for the SA1121 slowness reported in #2975.

[bjornhellander]

Do you have time to review this, @sharwell?

I would also like to cache complete StyleCopSettings objects, since merging the json content with the analyzer options takes considerable time as well, but I am holding that off until this one is merged to make it a bit easier to review.

[sharwell]

📝 So this is a bit of a strange situation. The AnalysisContext.TryGetValue<TValue> method is effectively static - it doesn't access any state of AnalysisContext. In theory, you could do something like this:

delegate bool TryGetStyleCopSettingsFileJson(SourceText text, SourceTextValueProvider<Lazy<JsonValue>> valueProvider, out Lazy<JsonValue> value);

// This delegate can be captured and used in the callback
TryGetStyleCopSettingsFileJson tryGetValue = context.TryGetValue<Lazy<JsonValue>>;

[sharwell]

For cases where more than one callback is registered, it does seem like it would be more efficient to use an explicit start callback and only compute it once.

[bjornhellander]

The big problem right now is re-creating the settings object over and over. Holding on to these two comments for later, when most of the work is done.

[bjornhellander]

For cases where more than one callback is registered, it does seem like it would be more efficient to use an explicit start callback and only compute it once.

Handled in #3648

[sharwell]

💡 Would be easy to use SourceTextReader to avoid the call to ToString() here

[bjornhellander]

Absolutely. Will do.

[bjornhellander]

Handled in #3648

[sharwell]

💡 It would be better to make this a static lambda in the call to GetSettingsFile so it can cache the delegate

[bjornhellander]

You lost me :-) This local function captures the context. I hadn't heard of static lambdas before, but it seems the context makes it impossible for it to be static. I am probably misunderstanding you (or static lambdas). Could you elaborate, @sharwell?

[sharwell]

Suppose you need to capture a local variable, like this:

int specialValue = 5;
InvokeHelper(() => specialValue);

// helper
int InvokeHelper(Func<int> calculateValue)
  => -calculateValue();

You can avoid the delegate allocation by making a generic state argument, and then making the lambda static:

int specialValue = 5;
InvokeHelper(static specialValue => specialValue, specialValue);

// helper
int InvokeHelper<TArg>(Func<TArg, int> calculateValue, TArg arg)
  => -calculateValue(arg);

[bjornhellander]

Ah, got it! So if I change GetSettingsFile to accept a generic state/context parameter the way you suggest, would there be any difference between a static lambda and making the existing local function static? I just feel that a local function is better for readability.

[sharwell]

I'm not sure. We'd need to look at the IL output from the compiler to verify.

[bjornhellander]

I am not fluent in IL, but it looks like a branch around the allocation if it has already been performed. Similar code for both static cases.
https://sharplab.io/#v2:EYLgtghglgdgNAFxFANnAJiA1AHwAIBMAjALABQeAzAASHUDC1A3udW7TXgCzUBiA9vwAUsBNQAeASmqt2LMu0XUA+tQC81ACLDxcWkQBs1AJ7qAfCckBuWWwC+tmQvZVaPAEIQATiJhipTorySuyqGtpCutQAMtaOivEuhtSiMb5ixtJqFsY2zvaOjq4AKlr8ADzFZkKlAG4QKACuAKZ6eACslXpV1BAAxghQ/DCSjsEhtADsvQNDMEL1Tc1x+dQOZHZAA=

[bjornhellander]

Handled in #3648

[sharwell]

💡 It would be better to make this a static lambda in the call to GetSettingsFile so it can cache the delegate

[bjornhellander]

Handled in #3648

[sharwell]

@bjornhellander The suggestions above can be implemented as part of the follow-up work