review.tizen.org Git - platform/upstream/dotnet/runtime.git/log

projects / platform / upstream / dotnet / runtime.git / log

Lakshan Fernando [Mon, 22 May 2023 14:45:13 +0000 (07:45 -0700)]

disable JitOptimizationSensitive check on NativeAOT testing (#86523)

Stephen Toub [Mon, 22 May 2023 14:34:54 +0000 (10:34 -0400)]

Lots of tweaks to FrozenDictionary/Set analysis and hashing (#86293)

- Some minor internal refactorings, e.g. changed the internal KeyAnalyzer.Analyze from being void returning with an out results to instead just return those results, and did some internal renaming.
- We were previously computing the min/max string length in KeyAnalyzer.Analyze twice, once in UseSubstring and then again after that in Analyze.  We were also computing it in the length buckets analyzer.  Changed the code to do the checks just once at the beginning and then pass that information around to everywhere that needs it.
- Once that information is passed in, AnalysisResults can then be made readonly, rather than being mutated to store the min/max after it was constructed.
- If the min length is 0, there's no point calling TryUseSubstring as it'll never find one, so skip the call to it entirely if there's an empty string in the mix.
- In TryUseSubstring, for a given substring length first check all the left justifications and then check all the right justifications, rather than intermingling them.  Left justifications are a bit cheaper to look up, plus we can avoid creating any objects related to checking right justification if we end up finding a left justification for a given substring length first.
- We can also avoid doing any right justification checks if all of the input strings are of the same length, as at that point there's nothing right justification could find that left justification couldn't.
- When constructing the HashSets for evaluating uniqueness, when targeting more recent .NET versions we can presize the HashSets to avoid the expansion as we add all the items.
- Importantly, set a limit on the maximum length of substring we'll consider.  This significantly curtails the worst-case analysis performance for very large inputs that don't yield any unique substrings.  While it's certainly possible to construct cases where this will then fail to find a substring when it otherwise could, it's much more rare, and the longer we're dealing with the less we're saving on the hashing costs, which is the only thing this is avoiding.
- For hashing, create dedicated branchless hash checks for each of lengths 0 to 4.
- When we're doing the ASCII check to see if we can use an ASCII-optimized comparer, if OrdinalIgnoreCase was used, we can also check to see if the substring contains any ASCII letters; if the only the thing the substrings contain are ASCII non-letters, then we can switch to being case-sensitive, as no casing will impact the comparisons.
- The ASCII check downlevel was erroneously including 0x7f as being non-ASCII. Fixed it to be 0x80 instead of 0x7f.
- Changed GetHashCodeOrdinalIgnoreCase to delegate to GetHashCodeOrdinal after doing its non-ASCII casing work.
- On .NET 6+, we can use GetValueRefOrAddDefault to avoid some dictionary lookups.
- For the length-bucketing implementation, we can do a quick up-front check to rule out applicability of many inputs where we know just based on the number of input strings and the min/max lengths whether some bucket will be forced to be too big.