ServerComponentRenderingTest.CanDispatchAsyncWorkToSyncContext is quarantined but since it's not running on Helix there isn't any history available for it. With all the moving
parts in the server test, it's unclear if it's a product vs test setup issue.
Authoring a more simplified test so we can track test history. Note that it's starting off as quarantined because there's no evidence that the product code isn't broken
Fixes https://github.com/dotnet/aspnetcore/issues/19413
* Improve CSharpLanguageCharacteristics.MapKeyword performance
The razor typing perf test profile I'm looking at has 156 ms of CPU cycles spent in this method, mostly in Enum.ToString()
\n\nCommit migrated from e821a4642e
* Add a scenario for measuring navigating between components
* Apply suggestions from code review
Co-authored-by: Steve Sanderson <SteveSandersonMS@users.noreply.github.com>
Co-authored-by: Steve Sanderson <SteveSandersonMS@users.noreply.github.com>
In the razor perf typing test, Accept was showing 27 ms allocating enumerators. Additionally, modified ReadWhile to only allocate if it would return a non-empty collection (and to not use the complexity introduced by using yield enumerators)\n\nCommit migrated from 27a14af36a
The razor perf test shows about 70 ms CPU of WithSpanContext is in allocation. GetAnnotation similarly is showing about 60 ms in allocation (of which this only partly improves)\n\nCommit migrated from a060f129ff
Our razor typing test measured 153 CPU ms in this method. Optimized by fewer calls to CurrentCharacter, not checking '<' twice, and uswing a switch stmt.\n\nCommit migrated from c601c2f11e
* Several changes targeted to improving perf of RazorSyntaxTree.Parse
1) Modify ParserHelpers.IsNewLine to use a switch instead of Array.IndexOf
2) Modify Tokenizer.CreateToken to take in an array of RazorDiagnostics rather than an IReadOnlyList as that was causing a ToArray call on an empty diagnostics very often (during a SyntaxFactory.Token call)
3) Modify TokenizerBackedParser.Putback to allow an IReadOnlyList as a parameter to not require creation of a reverse enumerator.
4) Cut down allocations in HtmlMarkupParser.GetParserState by:
a) Using an IReadOnlyList instead of IEnumerable to get rid of the allocations from the .any calls
b) Don't allocate while reading initial spacing
c) Inline the IsSpacingToken code so cut down on code executed and need to allocate a separate Func
5) Modify CSharpCodeParser.IsSpacingToken to now be a set of methods instead of a single method that allocates a Func. This is a very high traffic method.
6) Implement a fairly rudimentary Whitespace token cache, as they can be reused. This was based off Roslyn's SyntaxNodeCache, but simplified significantly. It's probably worth investigating whether you should more fully embrance token caching outside of whitespace.
* PR feedback and added one more optimization in LocateOwner that's been bugging me for years. Assuming all chidlren are contained within a nodes span, we can short-circuit the DFS this code was doing significantly cutting time in this method which is important as it's exercised on the main thread during typing.
* missed a space
* StringTextToSnapshot's switch to IsNewLine needed to use start as the index to begin the search, not zero.\n\nCommit migrated from 45411f7526
Wthout that fix following error on clean cmd without MBuild on path
```
eng\tools\RepoTasks\RepoTasks.csproj : error : Version 5.0.100-preview.5.20251.2 of the .NET Core SDK requires at least version 16.5.0 of MSBuild. The current available version of MSBuild is 16.3.0.463.05. Change the .NET Core SDK specified in global.json to an older version that requires the MSBuild version currently available.
```
* Use a dedicated thread for timers in rather than a Timer
- This make it possible to still timeout various operations when there's thread pool starvation occurring.
- Print heartbeat slow if duration > interval
- set `$env:DOTNET_CLI_HOME` because we need to install global tools in this repo
- without this, we see `dotnet-serve` installation failures on unclean machines
I noticed several hundred ms spent in this method from a customer profile. Primarilly, the method was doing a linear scan of all lines trying to find one that contained the requested position. I changed this to a binary search, but kept/improved the optimization around checking next/previous lines before instigating the search.
Note, there was also a bug where the old code did:
else if (absoluteIndex > _currentLine.Index && _currentLine.Index + 1 < _lines.Count)
but it should have been coparing absoluteIndex with _currentLine.Start
\n\nCommit migrated from 32a0f28708
* Tries to increase the reliability of the tests by:
* Trying to ensure that the server is up and running before connecting.
* Retrying a connection attempt multiple times.
* Update SDK to preview.5.20251.2
- includes support for the `net5.0` TFM
- includes fix for `$(PublishDepsFilePath)`
- includes fix for incorrect NU5118 warnings when `'$(PackAsTool)' == 'true'`
* !!temporary!! Suppress NU5129 warnings
- build/ and buildTransitive/ naming conventions do not treat TFMs as equivalent
* Run `InjectRequestHandlerOnPublish` later
- late enough for .deps file to exist i.e. after the `CopyFilesToPublishDirectory` target
- `AfterTargets` is a bit flaky; use `BeforeTargets` with empty targets instead
* Always add `@(AssemblyAttribute)` items before they are processed
- use `BeforeTargets="GetAssemblyAttributes"` for consistently throughout the repo
* Move template specific helpers out of shared and into templates
* More debug info, fix casing issues
* Keep test skipped
* Undo lock changes
* Standarize retry logic
* Tweak certificate validation code
John Luo
dotnet-maestro[bot]
Doug Bunting
Hao Kung
Pranav K
Todd Grunke
sanyam142mittal
Ben Adams
Andrii Kurdiumov
Safia Abdalla
N. Taylor Mullen
Brennan
Javier Calvarro Nelson
David Fowler
Andrew Stanton-Nurse
Christian Wenz
Andrew J Said
William Godbe
Sébastien Ros